Cisco Crosswork Data Gateway

ここでは、次の内容について説明します。

Crosswork Data Gateway の概要

Cisco Crosswork Data Gateway は、マルチベンダーデバイスからネットワークデータを収集するためのセキュアな共通の収集プラットフォームです。これは、MDT、SNMP、CLI、gNMI、および Syslog を含む複数のデータ収集プロトコルをサポートするネットワークデバイスの近くに展開される、オンプレミスのアプリケーションです。


（注）  

NETCONF データ収集のサポートは、 Crosswork Network Controller 6.0 リリース以降では廃止されています。

データゲートウェイとも呼ばれる Crosswork Data Gateway の必要な数および展開プロファイル（標準または拡張）は、サポートされるデバイスの数、処理するデータの量、収集する頻度、およびネットワークアーキテクチャによって異なります。

データゲートウェイが Cisco Crosswork インフラストラクチャ（このガイドでは Cisco Crosswork とも呼ばれます）で展開されている場合、Cisco Crosswork はコントローラアプリケーションとして機能します。

Crosswork Data Gateway では次の概念を使用します。

  • Crosswork Data Gateway インスタンス：インストールする Crosswork Data Gateway（データゲートウェイ）インスタンス。

  • Crosswork Data Gateway プロファイル：データゲートウェイは、次の展開プロファイルをサポートしています。

    • [標準（Standard）]：Crosswork Health Insights と Crosswork Service Health（Automated Assurance）を除くすべての Crosswork アプリケーションで使用します。

    • [拡張（Extended）]：Crosswork Health Insights と Crosswork Service Health（Automated Assurance）で使用します。


    注目
    [追加のリソースを備えた標準（Standard with Extra Resources）] プロファイルは、利用制限付きの機能として使用できますが、データセンターにデータゲートウェイを展開している間は使用しないでください。

  • Crosswork Data Gateway プール：高可用性を有効にするオプションを備えた 1 つ以上のデータ ゲートウェイ インスタンスで構成される論理ユニット。データ ゲートウェイ インスタンスがダウンすると、Cisco Crosswork は自動的にインスタンスをプールのスペアで置き換えてデバイスを管理し、データ収集の中断を最小限に抑えます。

  • Crosswork Data Gateway：データゲートウェイプールに追加されたときに仮想 IP アドレスが割り当てられるデータ ゲートウェイ インスタンス。

    デバイスの接続または切断、収集ジョブの作成などの操作は、データゲートウェイで行われます。

  • データ送信先：データゲートウェイによって収集されたデータの内部または外部の受信者。デフォルトでは、Cisco Crosswork はデータの接続先として定義されます。その他の接続先（外部ユーザー）は、Cisco Crosswork の UI または API を使用して定義できます。

  • 収集ジョブ：データゲートウェイがデータを収集するために実行する必要があるタスク。Crosswork アプリケーションは、デバイスの到達可能性を確認し、ネットワークとサービスの正常性を判断するために必要なテレメトリデータを収集する収集ジョブを作成します。Cisco Crosswork の UI と API を使用すると、Crosswork 以外のアプリケーションの収集ジョブを設定できます。

  • カスタム ソフトウェア パッケージ：デバイスカバレッジを拡張し、現在サポートされていないデバイスからのデータ収集をサポートするためのファイルとデバイスモデルの定義。


（注）  

この章では、Cisco Crosswork の UI を介してアクセスできるデータゲートウェイの機能についてのみ説明します。

データ ゲートウェイ インスタンスのインタラクティブコンソールとその管理方法の詳細については、「付録 A：Crosswork Data Gateway インスタンスの設定」を参照してください。

Crosswork Data Gateway の UI の概要

Crosswork Data Gateway の管理ビューを開くには、Cisco Crosswork にログインし、左側のナビゲーションバーから [管理（Administration）] > [Data Gatewayの管理（Data Gateway Management）] を選択します。

図 1. [データゲートウェイの管理（Data Gateway Management）] ウィンドウ
[データゲートウェイの管理（Data Gateway Management）] ウィンドウ

[Data Gateway の管理（Data Gateway Management）] ページには、次の 3 つのタブがあります。

  • [データゲートウェイ（Data gateways）]：ネットワーク内の仮想データゲートウェイの詳細を表示します。このタブから Data Gateway にデバイスを接続または切断できます。

  • [プール（Pools）]：データゲートウェイプールを管理します。

  • [データゲートウェイインスタンス（Data gateways instances）]：仮想データ ゲートウェイ インスタンスを管理します。

ドーナツグラフの可視化の横にある凡例をクリックして、テーブルをフィルタリングできます。たとえば、管理状態が [アップ（Up）] になっているプールを表示するには、[管理状態（Administration state）] チャートの横にある [アップ（Up）] アイコンをクリックします。テーブルは、[アップ（Up）] 状態のプールをフィルタリングします。

テーブルに表示する列を選択するには、テーブルの右上隅にある [設定（Settings）] アイコンをクリックし、関連するチェックボックスをオンにします。列を非表示にするには、チェックボックスをオフにします。

データゲートウェイ UI のすべてのテーブルでは、空のフィールドをクリックし、メニューから [すべて選択（Select all）] を選択することで、項目を複数選択できます。選択したすべての項目がテーブルに表示されます。選択を解除するには、選択した項目の横にある [X] アイコンをクリックします。

次の表では、[データゲートウェイの管理（Data Gateway Management）] ページのさまざまな列について説明します。

表 1. Crosswork Data Gateway の UI

カラム

説明

動作状態（Operational State）

データ ゲートウェイ インスタンスの動作状態。

データ ゲートウェイ インスタンスの動作状態は次のとおりです。

  • [低下（Degraded）] アイコン [低下（Degraded）]：

    データ ゲートウェイ インスタンスは到達可能ですが、1 つ以上のコンポーネントが [OK] 以外の状態です。

  • [アップ（Up）] アイコン [アップ（Up）]：データ ゲートウェイ インスタンスが動作しており、個々のすべてのコンポーネントは「OK」です。

  • [エラー（Error）] アイコン [エラー（Error）]：

    データ ゲートウェイ インスタンスが到達不能であるか、またはその一部のコンポーネントがエラー状態になっています。

管理状態（Administration state）

データ ゲートウェイ インスタンスの管理状態。状態は次のいずれかです。

  • [アップ（Up）] アイコン [アップ（Up）]：インスタンスは管理上のアップ状態です。

  • [メンテナンスモード（Maintenance Mode）] アイコン [メンテナンス（Maintenance）]：アップグレードやその他のメンテナンスアクティビティ（証明書のアップロードなど）を実行するために、Cisco Crosswork とデータゲートウェイ間の操作が中断されます。

高可用性ステータス（High availability status）

データゲートウェイの高可用性のステータスは次のいずれかです。

  • [保護されている（Protected）]：すべてのインスタンスが稼働しており、プール内に 1 つ以上のスタンバイがあります。

  • [保護されていない（Not protected）]：すべてのスタンバイインスタンスが DOWN 状態です。

  • [限定的な保護（Limited protection）]：一部のスタンバイインスタンスが DOWN 状態ですが、1 つ以上のスタンバイが UP 状態です。

  • [計画なし（None planned）]：プールの作成時にスタンバイインスタンスがプールに追加されませんでした。

デバイス（Devices）

データゲートウェイのプールに接続されているデバイスの数。

名前（Name）

データ ゲートウェイ インスタンスの名前。

名前の横にある アイコンをクリックすると、各インスタンスの登録の詳細が表示されます。これには、次が含まれます。

  • 仮想 IP アドレス

  • データ ゲートウェイ インスタンス名

  • 説明

  • データゲートウェイのプロファイルを示すデータゲートウェイのインスタンスタイプ。

  • データ ゲートウェイ インスタンスの UUID

インスタンス名をクリックして、データゲートウェイのバイタルページを開きます。このページには、データゲートウェイの動作と正常性の概要が表示されます。

プール名（Pool name）

データゲートウェイプールの名前。プール名をクリックすると、データゲートウェイのバイタルページが開きます。

サイト名（Site name）

データ ゲートウェイ インスタンスが割り当てられているサイト。

（注）  

 

この列は、Geo 冗長性機能が有効になっている場合にのみ表示されます。

Geo 冗長性機能の詳細については、『Cisco Crosswork Network Controller 7.0 Installation Guide』の「Enable Geo Redundancy」セクションを参照してください。

データ ゲートウェイ インスタンスのロール（Data gateway instance role）

データ ゲートウェイ インスタンスの現在のロールを示します。ロールは次のいずれです。

  • [割り当て済み（Assigned）]：データ ゲートウェイ インスタンスはプールに接続されています。

  • [未割り当て（Unassigned）]：データ ゲートウェイ インスタンスはどのプールにも接続されていません。

  • [スペア（アクティブ）（Spare (Active)）]：データ ゲートウェイ インスタンスは、アクティブサイトでのフェールオーバープロセス中に使用できるスペアインスタンスです。

  • [スペア（スタンバイ）（Spare (Standby)）]：データ ゲートウェイ インスタンスは、スタンバイサイトでのフェールオーバー手順のスペアインスタンスとして機能します。

停止履歴（Outage history）

データ ゲートウェイ インスタンスの 14 日間の停止履歴。

1 日の状態集約は、[エラー（Error）]、[低下（Degraded）]、[アップ（Up）]、[不明（Unknown）]、[準備中（Not Ready）] の優先順位で実行されます。

たとえば、データ ゲートウェイ インスタンスが [不明（Unknown）] から [低下（Degraded）] の後、[アップ（Up）] になった場合、当日は [低下（Degraded）] の色（オレンジ）で表示されます。これは、[アップ（Up）] や [不明（Unknown）] よりも [低下（Degraded）] のほうが優先されるためです。

データゲートウェイがその日の任意の時点で [エラー（Error）] 状態になった場合、タイルは赤になります。Data Gateway が [エラー（Error）] ではなく、[低下（Degraded）] 状態の場合、そのタイルはオレンジ色になります。データゲートウェイが [エラー（Error）] または [低下（Degraded）] 状態ではなく、[アップ（Up）] のみであった場合、タイルは緑色です。

平均可用性（Average availability）

データ ゲートウェイ インスタンスの正常性を示す値。このパーセンテージは、最初のイベントの開始時刻と最後のイベントの終了時刻の間に、データゲートウェイが UP 状態であった合計時間（ミリ秒単位）として計算されます。

（注）  

 
最後のイベントの終了時刻は現在のタイムスタンプであるため、最後のイベントの期間は開始時刻と現在のタイムスタンプの間になります。

データゲートウェイインスタンス名（Data gateway instance name）

データ ゲートウェイ インスタンスをプールに追加するときに自動的に作成されるデータゲートウェイの名前。

インスタンス名の横にある アイコンをクリックすると、各インスタンスの登録の詳細が表示されます。これには、次が含まれます。

  • インスタンス名

  • 説明

  • インスタンス タイプ

  • インスタンスロール

  • CPU

  • メモリ

  • NIC の数

  • インスタンス UUID

  • インスタンス OS バージョン

  • インターフェイス名

  • インターフェイスロール

  • インターフェイス MAC

  • インターフェイス名

[追加のインターフェイスロール情報（Additional interface role information）] では、データゲートウェイで使用できるインターフェイスロールについて説明しています。

接続デバイス数（Attached device count）

データゲートウェイプールに接続されているデバイスの数を示します。

PDG識別子（PDG identifier）

物理データ ゲートウェイ インスタンスの一意の識別子。

アクション（Actions）

[その他（More）] アイコン をクリックして、プールで実行できるアクションを表示します。

[Crossworkホーム（Crosswork Home）] ページ > [ダッシュボード（Dashboard）] で Crosswork Data Gateway ダッシュレットを設定できます。ダッシュボードでは、ダッシュレットをカスタマイズして、データ ゲートウェイ インスタンスとプールの概要を表示できます。ダッシュボードの使用の詳細については、トポロジマップの概要を参照してください。

データを収集するための Crosswork Data Gateway の設定

データゲートウェイをセットアップする前に、Crosswork のセットアップ方法を十分に理解しておく必要があります。詳細については、設定のワークフローを参照してください。

Crosswork Data Gateway では、収集ジョブを実行してデータを Crosswork に送信する前に、まず次のセットアップタスクを実行する必要があります。


（注）  

このワークフローでは、『Cisco Crosswork Network Controller 7.0 Installation Guide』で説明されているように、Crosswork Data Gateway がすでにインストールされていることを前提としています。

次の表の手順 1 から手順 3 までを実行して、Crosswork Data Gateway を設定し、Cisco Crosswork とその他の Crosswork アプリケーションで実行します。手順 4 〜手順 6 はオプションであり、外部のデータ送信先とカスタム収集ジョブを作成してデータを収集および転送する Crosswork Data Gateway の機能を拡張する場合にのみ必要です。

次のタスクは、Crosswork がシスコデバイスに対してサポートするデフォルト設定に従ってリストされています。オプションのタスクは、高度な機能を使用する場合にのみ必要です。

表 2. データ収集の目的で Crosswork Data Gateway をセットアップするためのタスク

タスク

次の手順を実行します。

1. データゲートウェイプールの作成。

Data Gateway プールの作成

2. （オプション）Geo 冗長性有効サイトにデータゲートウェイプールを作成する。

 Geo 冗長性が有効なサイトでのプールの作成

2. デバイスをデータゲートウェイに接続します。

Crosswork Data Gateway へのデバイスの接続

3. デフォルトの収集ジョブが作成され、正常に実行されていることを確認します。

収集ジョブのモニター

4. （オプション）デバイスカバレッジを拡張して、現在サポートされていないデバイスまたはサードパーティ製デバイスからデータを収集する。

デバイス パッケージ

5. （オプション）データを外部のデータ送信先に転送する。

外部データ送信先の作成と管理

6. （オプション）Cisco Crosswork によって作成された収集ジョブから独立したカスタム収集ジョブを作成する。

Crosswork Data Gateway の収集ジョブ

プールによる Crosswork Data Gateway の高可用性

Crosswork Data Gateway プールによって、最小限の中断でデバイス固有のデータ収集が行われます。

プールは、1 つ以上のデータ ゲートウェイ インスタンスで構成でき、オプションとして高可用性を有効にできます。

プール内のデータ ゲートウェイ インスタンスがダウンした場合、Cisco Crosswork によりそのインスタンスがプールのスタンバイインスタンスに自動的に置き換えられます（フェールオーバー）。または、手動でフェールオーバーを開始できます。フェールオーバーを開始する方法については、手動フェールオーバーの実行を参照してください。

[動作状態（Operational state）] が [エラー（Error）] で、[保護されている（Protected）] プールの一部であるデータ ゲートウェイ インスタンスは、フェールオーバーに適格です。障害が発生したインスタンスからスタンバイインスタンスへ、デバイスと既存の収集ジョブが自動的に割り当てられます。ダウンしたインスタンスが動作可能になると、プール内のスタンバイインスタンスになります。

図 2. Crosswork Data Gateway の高可用性

（注）  

プール内のデータゲートウェイの複数のインスタンスに同じサウスバウンド IP アドレスがある場合にスタンバイ データ ゲートウェイを再起動して、そのスタンバイ データ ゲートウェイ インスタンスがアップ状態になったときにそのサウスバウンド IP アドレスが失われるようにします。

たとえば、サウスバウンド IP アドレスを持つ CDG1（アクティブ）が、ポートの障害またはケーブルの切断が原因で応答しなくなったとします。Crosswork Network Controller はこれを検出し、CDG2（スタンバイ）をアクティブにして CDG1 と置き換えます。この時点で、CDG1 とその代替は、デバイスに接続する IP アドレスが同じになります。したがって、応答不能の原因となっている問題が解決され、プールに再参加できるようになるまで、競合を回避するために、障害が発生したデータゲートウェイの電源を（VMware を介して）オフにすることが不可欠です。

Crosswork Data Gateway のプールには次の状態があります。

  • [保護されている（Protected）]：すべてのインスタンスが稼働しており、プール内に 1 つ以上のスタンバイインスタンスがあります。

  • [保護されていない（Not protected）]：すべてのスタンバイインスタンスが DOWN 状態であり、使用中のインスタンスを置き換えることができません。

  • [限定的な保護（Limited protection）]：一部のスタンバイインスタンスが DOWN 状態ですが、1 つ以上のスタンバイが UP 状態です。

  • [計画なし（None planned）]：プールの作成時にスタンバイインスタンスがプールに追加されませんでした。

データ ゲートウェイ マネージャは、登録されている各データゲートウェイの定期的なハートビートまたは活性度チェックを 10 秒間隔で実行します。データゲートウェイが 6 回の活性度チェック（約 60 秒かかる）内に応答しない場合、データ ゲートウェイ マネージャはデータゲートウェイがエラー状態であると見なします。

データゲートウェイが自身の正常性ステータス内にノースバウンド通信のインターフェイス接続の問題を通知した場合、活性度チェックにも応答し、エラー状態を報告することもあります。

データ ゲートウェイ マネージャは、データゲートウェイの動作状態を 20 秒ごとにチェックします。アクティブインスタンスがエラー状態になると、データ ゲートウェイ マネージャはフェールオーバーを開始し、プールのスペアインスタンスが新しいアクティブインスタンスになります。

Data Gateway プールの作成

始める前に

データゲートウェイプールを作成する前に、次の点を確認してください。

  • 特定のフィールドと設定オプションには、Geo 冗長性機能が有効になっている場合にのみアクセスできます。Geo 冗長性機能の詳細については、『Cisco Crosswork Network Controller 7.0 Installation Guide』の「Enable Geo Redundancy」セクションを参照してください。

  • データゲートウェイは、syslog 証明書にデータゲートウェイの仮想 IP アドレスの代わりにホスト名または FQDN が含まれている必要があるデバイスへの安全な syslog 通信をサポートします。これは、syslog 証明書にホスト名または FQDN を持つことを義務付けるデバイスで有効にできるオプション機能です。有効にすると、Cisco Crosswork は、DNS サーバーからデータゲートウェイの各仮想 IP アドレスのホスト名または FQDN をフェッチします。新しく追加された仮想 IP の FQDN は、プールを保存した後に取得されます。その後、syslog 証明書には、データゲートウェイの仮想 IP アドレスの代わりに、CN および SAN に FQDN が含まれます。デバイスでセキュア Syslog を設定する方法の詳細については、「デバイスでのセキュア Syslog の設定」を参照してください。

  • 仮想 IP アドレス（アクティブなデータゲートウェイごとに 1 つの仮想 IP）、サブネットマスク、ゲートウェイ情報などのネットワーク情報を用意します。


    （注）  

    3 NIC 展開の場合は、ネットワークデバイスへのアクセスに使用するゲートウェイ アドレスも指定する必要があります。

    展開内の vNIC の数に応じて、仮想 IP アドレスは次のようになります。

    • 2 NIC 展開用のデータネットワーク上の追加 IP アドレス。

    • 3 NIC 展開用のサウスバウンドネットワーク上の IP アドレス。

  • プール内の仮想 IP アドレスの FQDN を有効にするかどうかを決定します。はいの場合、プールを正常に作成するために、DNS サーバーで仮想 IP の FQDN が設定されていることを確認してください。

  • 少なくとも 1 つのデータゲートウェイがインストールされていることを確認します。高可用性が必要な場合は、少なくとも 2 つのデータ ゲートウェイ インスタンスをインストールしてください。データ ゲートウェイ インスタンスの数は、ネットワーク要件によって決まります。サポートが必要な場合は、シスコのカスタマー エクスペリエンス チームにお問い合わせください。

  • 動作状態が NOT_READYに設定されたデータゲートウェイが、少なくとも 1 つ Crosswork Network Controller に登録されていることを確認します。高可用性構成では、複数のデータ ゲートウェイ インスタンスが必要です。

  • 不均衡なプールには Crosswork またはサイトの障害に対する保護機能がないため、プールの均衡が取れていることを確認します。

プールの UI 用語

プールを作成するときに情報に基づいた選択を行うために、以下の UI コントロールを理解することをお勧めします。

  • Crosswork では、データセンターに固有のカスタムプールタイプを作成できます。VMware の場合は VIP に基づいてプールを作成できますが、Amazon EC2 およびクラウドベースの展開の場合は FQDN を使用してプールを作成できます。

    • [VIPベース（VIP-based）]：単一の IP サブネットに存在する HA プールの一部であるデータ ゲートウェイ インスタンスに接続するネットワークデバイス。サブネットは、DC（データセンター）内であるか、DC 間に拡張されている場合があります。

    • [FQDNベース（FQDN-based）]：ネットワークデバイスがデータ ゲートウェイ インスタンスに接続するプールが、同じ HA プール内で複数のサブネットにまたがります。データゲートウェイ HA プールの内部サブネットアドレスを保護するには、VIP のホストとして機能する外部ネットワークロードバランサ（NLB）を使用して、トラフィックをネットワークデバイスに転送します。

  • VIP 構成を選択する際に、次のいずれかを選択する必要があります。

    • [共有VIP（Shared VIP）]：アクティブサイトとスタンバイサイトの VIP が同じサブネット内に存在する場合は、[共有VIP（Shared VIP）] オプションを選択できます。これは、両方のサイトでデータ ゲートウェイ インスタンスの VIP が共有され、[グローバルプールパラメータ（Global Pool Parameters）] ペインで確認できることを意味します。

    • [サイト固有VIP（Site Specific VIP）]：アクティブサイトとスタンバイサイトの VIP が異なるサブネットに存在している場合は、[サイト固有VIP（Site Specific VIP）] オプションを選択する必要があります。この場合、各サイトのデータ ゲートウェイ インスタンスは個別の VIP を持ち、それぞれのサイトペインで設定する必要があります。

プール作成のガイドライン

データゲートウェイプールを設定する場合は、プールをシームレスに作成できるように、次のガイドラインに従うことが重要です。

  • 少なくとも 1 つのプールを作成し、データ ゲートウェイ インスタンスをそのプールに割り当てます。収集用のデータゲートウェイを設定するには、この手順が必須です。

  • プール内のすべてのデータ ゲートウェイ インスタンスは、同じ構成（Standard、または Extended）である必要があります。

  • DNS サーバーで VIP の FQDN 構成が欠落している場合、プールの作成は失敗します。DNS サーバーで FQDN 構成を確認するか、FQDN オプションを無効にして再試行してください。

  • Crosswork がデュアルスタックで展開されている場合は、データ ゲートウェイ インスタンスもデュアルスタックで展開されていることを確認して、インスタンス間のデータ転送がスムーズに行われるようにします。デュアルスタック展開の場合は、VIP IPv4 アドレスと IPv6 アドレスの両方を持つプールを作成します。

  • AWS EC2 では、複数のアベイラビリティーゾーン（AZ）にまたがる Crosswork Data Gateway プールを構成する場合、1:1 の構成のみがサポートされます。このセットアップは、1 つのアクティブ データ ゲートウェイと 1 つのスタンバイ データ ゲートウェイで構成されます。つまり、各プールには 1 つのアクティブインスタンスと 1 つのスタンバイインスタンスのみを含めることができます。M:N 構成をサポートできるオンプレミスセットアップ（M がアクティブインスタンスを表し、N がスタンバイインスタンスを表す）とは異なり、AWS EC2 では、この 1:1 モデルを超える追加の冗長性は構成できません。

手順

ステップ 1

メインメニューから [管理（Administration）] > [データゲートウェイの管理（Data Gateway Management）] を選択し、[プール（Pools）] タブをクリックします。

ステップ 2

[ プール（Pools）] タブで [追加（Add）] アイコン ボタンをクリックし、次のいずれかを選択します。

  • [VIPベース（VIP-based）]

  • [FQDNベース（FQDN-based）}

プールの種類については、右上の [プールの種類（Types of pools）] をクリックしてください。[プールの作成（Create pool）] ページが開きます。

ステップ 3

[プールパラメータ（Pool parameters）] ペインで、VIP ベースまたは FQDN ベースのどちらのプールを選択したかに基づいて、適切なパラメータ値を入力します。

  • [プール名（Pool name）]：ネットワークを適切に説明する一意のプール名。

  • [説明（Description）]：プールの説明。

  • [IPv4サブネット（IPv4 subnet）]：各データゲートウェイのサブネットマスク。IPv4 サブネットマスクの範囲は 1 〜 32、ポートの範囲は 1024 〜 65535 です。

  • [IPv4ネットワークゲートウェイ（IPv4 network gateway）]：データゲートウェイは IPv4 ネットワーク ゲートウェイ アドレスを使用してデバイスと通信します。

  • [IPv6サブネット（IPv6 subnet）]：各データゲートウェイのサブネットマスク。IPv4 サブネットマスクの範囲は 1 〜 128、ポートの範囲は 1024 〜 65535 です。

  • [IPv6ネットワークゲートウェイ（IPv6 network gateway）]：データゲートウェイは IPv6 ネットワーク ゲートウェイ アドレスを使用してデバイスと通信します。

  • [スペアの数（Number of spare(s)）]：スタンバイインスタンスとして動作するデータ ゲートウェイ インスタンスの数。アクティブなデータゲートウェイが使用不可になったときに、スペアのゲートウェイがアクティブなゲートウェイの役割を担います。

  • （オプション）[仮想IPアドレスのFQDNを有効にする（Enable FQDN for virtual IP addresses）]：このオプションを選択して、syslog 証明書でデータゲートウェイの各仮想 IP アドレスにホスト名または FQDN を使用します。

  • [IPv4アドレス（IPv4 address(s)）]：データゲートウェイ VM の IPv4 アドレスを指定します。

  • [IPv6アドレス（IPv6 address(s)）]：別の VM に割り当てられていないことを確認しながら、データゲートウェイ VM の IPv6 アドレスを指定します。

  • [FQDN]：FQDN アドレスを指定します。

図 3. 単一スタック展開の VIP ベースのプール作成ウィンドウ
デュアルスタック展開のプールを作成する場合は、VIP IPv4 アドレスと IPv6 アドレスの両方を指定する必要があります。
図 4. デュアルスタック展開の VIP ベースのプール作成ウィンドウ
図 5. FQDN ベースのプールの作成ウィンドウ

ステップ 4

[+もう1つ追加する（+ Add another）]：前に選択したアドレスファミリ（IPv4 または IPv6、または両方、FQDN）に基づいて、すべてのアクティブなデータ ゲートウェイ インスタンスの仮想 IP アドレスまたは FQDN を入力します。

Geo 冗長性が有効な展開でプールを作成する場合、これ以降はGeo 冗長性が有効なサイトでのプールの作成の手順に従います。Geo展開以外の場合は、このドキュメントの手順を続行します。

ステップ 5

[データゲートウェイインスタンスの割り当て（Assign data gateway instance(s)] ペインで、左側の [未割り当てのデータゲートウェイインスタンス（Unassigned Data Gateway Instance(s)）] からデータ ゲートウェイ インスタンスを選択し、右矢印をクリックしてインスタンスを [割り当て済みのデータゲートウェイインスタンス（Assigned data gateway instance(s)）] に移動します。

ステップ 6

[作成（Create）] をクリックします。

Amazon EC2 で、プールが作成されたら、アクティブなデータゲートウェイの NLB が正常な状態であることを確認します。
[保存（Save）] をクリックすると、仮想データゲートウェイが自動的に作成され、[データゲートウェイインスタンス（Data gateway Instances）] タブに表示されます。デバイスをこの仮想データゲートウェイに接続して収集ジョブを実行します。

Geo 冗長性が有効なサイトでのプールの作成

Geo 冗長性が有効な展開のプールを作成する場合は、追加の VIP およびサイトパラメータを指定する必要があります。プールの作成プロセスは Geo が有効ではない展開に似ていますが、Geo 冗長性機能が有効になっている場合にのみ表示されるフィールドが追加されています。

次の手順では、追加のフィールドを設定する方法について説明します。

始める前に

続行する前に 、「Cisco Crosswork Data Gateway プールの作成」に記載の手順 1 ～ 4 を完了していることを確認します。

手順

ステップ 1

[プールパラメータ（Pool parameters）] ページには、作成するプールのタイプに応じて次の仮想 IP オプションが表示されます。

  • VIP ベースのプール：

    • [仮想IP構成（Virtual IP configuration）] で、[共有VIP（Shared VIP）] または [サイト固有VIP（Site-specific VIP）] を選択します。

    • [共有VIP（Shared VIP）] を選択した場合は、次の項目を入力します。

      • 仮想IPタイプ：仮想 IP の IPv4 または IPv6 アドレスファミリのいずれかを選択します。

      • デュアルスタック展開の場合は、仮想 IP の IPv4 と IPv6 アドレスファミリを指定します。

      • サブネット：各データゲートウェイのサブネットマスク。IPv4 サブネットマスクの範囲は 1 〜 32、ポートの範囲は 1024 〜 65535 です。

      • ネットワークゲートウェイ：データゲートウェイがデバイスと通信するために使用するアドレス。

    • [サイト固有VIP（Site-specific VIP）] を選択した場合は、仮想 IP の IPv4 または IPv6、またはデュアルスタックのアドレスファミリを選択して、 [仮想IPタイプ（Virtual IP type）] を指定します。

図 6. VIP ベースプールの作成ウィンドウ

  • FQDN ベースのプール：

    • [FQDN構成（FQDN configuration）] で、[共有FQDN（Shared FQDN）] または [サイト固有FQDN（Site-specific FQDN）] を選択します。

    • [共有FQDN（Shared FQDN）] を選択した場合は、次の項目を入力します。

      • 仮想IPタイプ：仮想 IP の IPv4 または IPv6 アドレスファミリのいずれかを選択します。

      • サブネット：各データゲートウェイのサブネットマスク。IPv4 サブネットマスクの範囲は 1 〜 32、ポートの範囲は 1024 〜 65535 です。

      • ネットワークゲートウェイ：データゲートウェイがデバイスと通信するために使用するアドレス。

    • [サイト固有 FQDN（Site-specific FQDN）] を選択した場合は、FQDN を指定します。

図 7. FQDN ベースプールの作成ウィンドウ

ステップ 2

[+もう1つ追加する（+ Add another）]：前に選択したアドレスファミリ（デュアルスタック、IPv4 または IPv6、FQDN）に基づいて、すべてのアクティブなデータ ゲートウェイ インスタンスの仮想 IP アドレスまたは FQDN を入力します。

ステップ 3

[データゲートウェイインスタンスの割り当て（Assign data gateway instance(s)] ペインで、左側の [未割り当てのデータゲートウェイインスタンス（Unassigned Data Gateway Instance(s)）] からデータ ゲートウェイ インスタンスを選択し、右矢印をクリックしてインスタンスを [割り当て済みのデータゲートウェイインスタンス（Assigned data gateway instance(s)）] に移動します。

図 8. シングルスタックの [アクティブ（Active）] ペイン
シングルスタックの [アクティブ（Active）] ペイン
図 9. デュアルスタックの [アクティブ（Active）] ペイン
デュアルスタックの [アクティブ（Active）] ペイン

ステップ 4

[スタンバイ（Standby）] ペインで、左側の [未割り当てのデータゲートウェイインスタンス（Unassigned Data Gateway Instance(s)）] からデータ ゲートウェイ インスタンスを選択し、右矢印をクリックしてインスタンスを [プールに追加されたデータゲートウェイインスタンス（Data gateway instance(s) added to pool）] に移動します。

図 10. シングルスタックの [スタンバイ（Standby）] ペイン
シングルスタックの [スタンバイ（Standby）] ペイン
図 11. デュアルスタックの [スタンバイ（Standby）] ペイン
デュアルスタックの [スタンバイ（Standby）] ペイン

ステップ 5

[作成（Create）] をクリックします。

Amazon EC2 で、プールが作成されたら、アクティブなデータゲートウェイのネットワークロードバランサが正常な状態であることを確認します。
[保存（Save）] をクリックすると、仮想データゲートウェイが自動的に作成され、[データゲートウェイインスタンス（Data Gateway Instances）] タブに表示されます。
Geo 冗長性が有効なサイトへのデータゲートウェイの割り当て

データゲートウェイは、アクティブサイトまたはスタンバイサイトに割り当てることができます。

始める前に

次の点を確認してください。

  • データ ゲートウェイ インスタンスは、Geo 冗長性機能が有効になっているサイトにのみ割り当てることができます。Geo 冗長性機能を有効にする方法の詳細については、『Cisco Crosswork Network Controller 7.0 Installation Guide』の「Enable Geo Redundancy」セクションを参照してください。

  • データゲートウェイが未割り当て状態の場合、それらをアクティブサイトまたはスタンバイサイトのいずれかに割り当てるオプションがあります。

  • データゲートウェイがプールのメンバーである場合は、プールの編集オプションを使用して Crosswork の移行中にのみサイトに割り当てることができます。Crosswork の移行中は、進行中の移行を示す通知が [データゲートウェイの管理（Data Gateway Management）] ページに表示されます。

手順

ステップ 1

メインメニューから、[管理（Administration）] > [データゲートウェイの管理（Data Gateway Management）] を選択して、[データゲートウェイインスタンス（Data Gateway Instances）] タブをクリックします。

ステップ 2

[サイトへのデータゲートウェイインスタンスの割り当て（Assign DG instance to site）] をクリックします。[サイトへのデータゲートウェイインスタンスの 割り当て（Assign data gateway instance(s) to site）] ウィンドウが開きます。ウィンドウには、未割り当ての状態のデータ ゲートウェイ インスタンスが表示されます。

ステップ 3

割り当てられたサイトを変更するデータ ゲートウェイ インスタンスを選択します。

ステップ 4

[サイトの選択（Select site）] ドロップダウンをクリックし、サイトを選択します。

ステップ 5

[割り当て（Assign）] をクリックします。

選択したサイトにデータ ゲートウェイ インスタンスが割り当てられたことを確認するメッセージが表示されます。[ 管理（Administration）] の [サイト名（Site name）] 列 > [データゲートウェイの管理（Data Gateway Management）] に移動し、[データゲートウェイインスタンス（Data gateway instances）] タブをクリックすると、変更された サイト 名が表示されます。

手動フェールオーバーの実行

計画されたメンテナンススケジュールがある場合、インスタンスから同じプール内にあるスタンバイインスタンスへのフェールオーバーを強制できます。

始める前に

Crosswork Data Gateway プールでフェールオーバーを開始する前に、次の点に注意してください。

  • 自動フェールオーバーが進行中のデータゲートウェイでは、手動フェールオーバーを試行できません。

  • Crosswork では、一度に 1 つのみのフェールオーバー要求が可能です。同時に複数のフェールオーバー要求をサポートしていません。

  • 少なくとも 1 つのインスタンスの動作状態が NOT_READY であることを確認します。Crosswork は、このインスタンスをフェールオーバーが発生するスタンバイと見なします。

  • スタンバイクラスタとアクティブクラスタの両方に少なくとも 1 つのスペアデータゲートウェイが存在し、ステータスが NOT_READYである必要があります。

  • メンテナンスモードのデータゲートウェイは、管理状態が [アップ（UP）] になるまで、将来のフェールオーバー手順のスペアとして使用できません。

以下の手順を使用して、Crosswork Data Gateway インスタンスの手動フェールオーバーを開始します。

手順

ステップ 1

メインメニューから、[管理（Administration）] > [データゲートウェイの管理（Data Gateway Management）] > [データゲートウェイ（Data gateways）] タブの順に選択します。

ステップ 2

フェールオーバーを開始する Crosswork Data Gateway の [アクション（Actions）] 列で、[フェールオーバーの開始（Initiate failover）] をクリックして選択します。

ステップ 3

[警告（Warning）] ウィンドウで、フェールオーバーの完了後に、選択したデータゲートウェイをメンテナンスモードに移行する場合は、チェックボックスをオンにします。

ステップ 4

[続行（Continue）] をクリックします。

次のタスク

フェールオーバーが発生すると、プライマリ データ ゲートウェイ（cdg1）はセカンダリ データ ゲートウェイ（cdg2）に切り替わり、cdg2 は cdg1 のサウスバウンド IPv6 アドレスを引き継ぎます。cdg2 が検出されると、Crosswok は cdg2 のイベントをログに記録し、IP アドレスが dg1 の設定と重複しているため、重複アドレス検出（DAD）障害を示します。この一時的なエラーは、オペレーティングシステムがインターフェイスから DAD 障害フラグを削除しているときに発生します。オペレーティングシステムがインターフェイスで DAD 障害ステータスをクリアすると、Crosswork はゲートウェイを [アップ（UP）] 状態に移行します。

エラーが原因でフェールオーバーが成功しない場合は、データ ゲートウェイのフェールオーバーが失敗するを参照してください。

Crosswork Data Gateway へのデバイスの接続

始める前に

  • デバイスを接続するデータゲートウェイの [管理状態（Admin state）] と [動作状態（Operational state）] が [アップ（Up）] であることを確認します。

  • Crosswork Network Controller では、一度に 1 つの Crosswork Data Gateway にのみデバイスを接続できます。

  • 最適なパフォーマンスを得るには、300 台以下のデバイスで数回に分けて Crosswork Data Gateway に接続することをお勧めします。

  • Crosswork Data Gateway は、いくつかのセキュア SSH キー交換アルゴリズムをサポートしています。SSH が失敗する場合は、デバイスが次のいずれかのキータイプを使用するように設定されていることを確認してください。

    • aes128-gcm@openssh.com

    • aes256-gcm@openssh.com

    • aes128-ctr

    • aes192-ctr

    • aes256-ctr

    • blowfish-ctr

    • aes128-cbc

    • aes192-cbc

    • aes256-cbc

    • blowfish-cbc

    • 3des-ctr

    • 3des-cbc

    • hmac-sha2-256

    • hmac-sha2-512

    • hmac-sha1-96

    • hmac-sha1

    • hmac-md5-96

    • hmac-md5

    • hmac-sha2-256-etm@openssh.com

    • hmac-sha2-512-etm@openssh.com

手順

ステップ 1

（オプション）既存の Crosswork Data Gateway にデバイスを接続する前に、Crosswork Data Gateway の正常性を確認することをお勧めします。詳細については、「Crosswork Data Gateway 正常性のモニタリング」を参照してください。

ステップ 2

メインメニューから、[管理（Administration）] > [データゲートウェイの管理（Data Gateway Management）] > [データゲートウェイ（Data gateways）] に移動します。

ステップ 3

デバイスを接続する Crosswork Data Gateway の [アクション（Actions）] 列で、[その他（More）] アイコン をクリックして [デバイスの接続（Attach devices）] を選択します。[デバイスの接続（Attach devices）] ウィンドウが開き、接続可能なすべてのデバイスが表示されます。

図 12. [デバイスの接続（Attach Devices）] ウィンドウ
[デバイスの接続（Attach Devices）] ウィンドウ

ステップ 4

すべてのデバイスを接続するには、[すべてのデバイスの接続（Attach all devices）] をクリックします。それ以外の場合は、接続するデバイスを選択し、[選択したデバイスの接続（Attach delected devices）] をクリックします。

ステップ 5

[確認：デバイスの接続（Confirm - Attach devices）] ダイアログで、[接続（Attach）] をクリックします。

[データゲートウェイ（Data gateways）] ペインの [接続デバイス数（Attached device count）] 列を確認して、変更が成功したことを確認します。

Crosswork Data Gateway の正常性をモニターし、Crosswork Data Gateway が新しく接続されたデバイスで正常に機能していることを確認します。正常性をモニターする方法については、Crosswork Data Gateway 正常性のモニタリングを参照してください。

Crosswork Data Gateway の設定後の管理

この項では、Crosswork Data Gateway 内のさまざまなメンテナンスタスクについて説明します。

Crosswork Data Gateway 正常性のモニタリング

[Crosswork Data Gateway のバイタル（Crosswork Data Gateway Vitals）] ページから、データゲートウェイの動作と正常性の概要を表示できます。このページにアクセスするには、[管理（Administration）] > [データゲートウェイの管理（Data Gateway Management）] > [データゲートウェイ（Data gateways）] に移動し、テーブルでプール名をクリックします。プールの詳細ページが開きます。このページには、データゲートウェイで実行されているさまざまなコンテナ化されたサービスの正常性の詳細も含まれています。データゲートウェイの全体的な正常性は、コンテナ化された各サービスの正常性にも依存します。

[アクション（Actions）] ボタンをクリックし、適切なメニューを選択することで、トラブルシューティング アクティビティを実行できます。

  • [Ping]：任意の IP アドレスへの到達可能性をチェックします。

  • [トレースルート（Trace Route）]：遅延の問題のトラブルシューティングに役立ちます。このオプションを使用すると、データゲートウェイが接続先に到達するまでの時間を予測できます。

  • [サービスメトリックのダウンロード（Download service metrics）]：Cisco Crosswork の UI からデータゲートウェイのすべての収集ジョブのメトリックをダウンロードします。

  • [Showtechのダウンロード（Download showtech）]：Cisco Crosswork の UI から showtech ログをダウンロードします。

  • [再起動（Reboot）]：データゲートウェイを再起動します。

  • [ログレベルの変更（Change log level）]：データゲートウェイのコンポーネント（コレクター（cli-collector）やインフラサービス（oam-manager）など）のログレベルを変更できます。ログレベルの変更は、変更を加えるデータゲートウェイにのみ適用されます。

図 13. [データゲートウェイ（Data Gateway）] ウィンドウ
[データゲートウェイ（Data Gateway）] ウィンドウ

次のパラメータがこのページに表示されます。

  • [一般的なCrosswork Data Gatewayの詳細（General Crosswork Data Gateway details）]：動作状態、高可用性の状態、接続されているデバイスの数、割り当てられたジョブなど、データゲートウェイの一般的な詳細を表示します。[アクション（Actions）] オプション UI から使用できるさまざまなトラブルシューティングのオプションについて説明します。

  • [履歴（History）]：タイムスタンプ、停止時間、クリア時間を含む、14 日間のデータゲートウェイの停止履歴チャートを表示します。ペインの右上隅のオプションを使用して、グラフ内の特定の期間の履歴チャートの拡大、縮小、パンを実行したり、SVG と PNG をダウンロードします。

  • [イベント（Events）]：過去 14 日間のデータゲートウェイの遷移状態のすべての変更のリストを表示します。これには、動作状態の変更、ロールの変更、ステータス変更の理由を示すメッセージ、タイムスタンプ、期間を含むイベントの詳細などの情報が含まれます。

  • [正常性（Health）]：データゲートウェイの正常性情報を示します。右上隅のタイムスタンプは、最後の正常性データが収集されたときのタイムスタンプです。データゲートウェイが [エラー（Error）] 状態の場合、または何らかの理由でデータが古い場合、タイムスタンプラベルはデータが古いことを示します。データゲートウェイの [CPU使用率（CPU utilization）] が 80% を超える場合は、[CPU使用率（CPU utilization）] がさらに増加してデータゲートウェイの障害につながる前に、是正措置を講じることをお勧めします。

    [ネットワーク入出力率（Network In/Out）] セクションには、vNIC がネットワークデータを送受信する速度が表示されます。

    [追加のロール情報（Additional role information）] の横にある [?] アイコンをクリックすると、vNIC に割り当てられたインターフェイスロールを表示できます。ポップアップには、使用可能なロールに関する情報が表示されます。

    図 14. [Crosswork Data Gatewayの正常性（Crosswork Data Gateway Health）] ウィンドウ
    [Crosswork Data Gatewayの正常性（Crosswork Data Gateway Health）] ウィンドウ

  • [サービスステータス（Service status）]：データゲートウェイで実行されている個々のコンテナサービスの正常性情報、およびそのリソース消費と個々のサービスを再起動するオプション（[アクション（Actions）] > [再起動（Restart）]）が表示されます。[負荷（Load）] 列は、その特定のコレクター/サービスの処理負荷を示します。コレクターの負荷スコアは、いくつかのメトリックを使用して計算されます。負荷スコアは、低、中、または高の重大度ゾーンにマップされます。コレクターが常に高ゾーンで動作している場合、そのコレクターが特定の CPU/メモリリソースプロファイルのピーク容量に達したことを意味します。負荷スコアの計算方法の詳細については、「Load Score Calculation」を参照してください。


    （注）  

    コンテナサービスのリストは、標準の Crosswork Data Gateway と拡張 Crosswork Data Gateway で異なります。拡張 Crosswork Data Gateway には、より多くのコンテナがインストールされています。

    表示されるリソース消費データは、docker 統計からのものです。これらの値は、コンテナ化されたサービスによって消費される実際のリソースよりも高くなります。
    図 15. [サービスステータス（Service Status）] ウィンドウ
    [サービスステータス（Service Status）] ウィンドウ

ネットワーク内のデータゲートウェイの正常性を定期的に監視して、過負荷を防止し、リソースを追加したり、データゲートウェイの負荷を削減するなどの是正措置を事前に講じることをお勧めします。

  1. データゲートウェイに障害が発生した場合、またはそのリソース容量の上限に近づいている場合、データゲートウェイマネージャはアラームを生成します。Crosswork UI から [Showtech要求（Showtech requests）] に移動して、またはアラームポッドにログインして、アラームの詳細を確認できます。

    アラームには、イベントのタイトル、重大度、構成ステージ（Day 0、1、または 2）、説明、および修復アクションが含まれます。[Showtech要求（Showtech Requests）] ウィンドウに移動する方法については、Crosswork Data Gateway アラームの表示を参照してください。

  2. データゲートウェイの [CPU使用率（CPU utilization）] が 80% を超える場合は、デバイスを別のデータゲートウェイに移動する、他の VM をプールに追加する、または既存の収集ジョブの頻度を減らす（パターンの時間を増やす）ことによって [CPU使用率（CPU utilization）] を下げるまで、追加の収集ジョブを作成しないことをお勧めします。

  3. データゲートウェイの [CPU使用率（CPU utilization）] が 90% を超える場合は、[CPU使用率（CPU utilization）] の低い別のデータゲートウェイにデバイスを移動することをお勧めします。

  4. システムアラームを毎週確認することをお勧めします。リソースの問題ではなく、データのドロップが頻繁に発生していないことを確認してください。次に、データの宛先の問題を修正するか、収集ジョブの頻度を減らします（パターンの時間を増やします）。

Crosswork Data Gateway アラームの表示

Crosswork Data Gateway は、データ収集を妨げる異常を検出すると、アラームを生成します。アラームを確認して、データ収集に影響を与える問題を把握し、必要に応じて修復アクションを実行できます。

アラームを表示するには、Crosswork UI に移動します。


（注）  

または、アラームポッドにログインして、DgManager.yaml ファイルでアラームを表示することもできます。
手順

ステップ 1

メインメニューから、[管理（Administration）] > [Crosswork Manager] > [アプリケーション管理（Application Management）] タブを選択し、[アプリケーション（Applications）] をクリックします。

ステップ 2

[プラットフォームインフラストラクチャ（Platform Infrastructure）] タイルで、[詳細の表示（View Details）] をクリックします。[アプリケーション詳細（Application Details）] ウィンドウが開きます。

ステップ 3

[マイクロサービス（Microservices）] タブで、[名前（Name）] フィールドにアラームを入力して、アラームポッドを見つけます。アラームポッドのステータスは、正常である必要があります。

ステップ 4

[アクション（Actions）] の下の アイコンをクリックし、[Showtech要求（Showtech requests）] を選択します。[Showtech要求（Showtech Requests）] ウィンドウに、Showtech ジョブの詳細が表示されます。

ステップ 5

（オプション）アラームポッドにログインしてアラームを表示するか、[公開（Publish）] をクリックしてアラームをダウンロードして Showtech ログを公開します。[宛先サーバーの入力（Enter Destination Server）] ダイアログボックスが表示されます。関連する詳細を入力し、[公開（Publish）] をクリックします。

図 16. [宛先サーバーの編集（Edit Destination Server）] ウィンドウ
アラームは、指定した接続先で公開されます。

Crosswork Data Gateway プールの編集または削除

始める前に

プールを編集または削除する前に考慮すべき重要なポイント：

  • 接続されているデバイスがある仮想データゲートウェイまたはプールは削除できません。

  • データ ゲートウェイ インスタンスは、すべてのデバイスのマッピングが Crosswork Data Gateway から削除された場合にのみ、プールから削除できます。データ ゲートウェイ インスタンスがプールから削除されると、フェールオーバー手順を実行した後に、同じプールのスタンバイインスタンスがその代替になります。手動フェールオーバーの詳細については、手動フェールオーバーの実行を参照してください。

  • データゲートウェイプールを削除する前に、最初にデータゲートウェイからデバイスを切り離すか、デバイスを別のデータゲートウェイに移動します。

次の手順を実行して、データゲートウェイプールを編集または削除します。

手順

ステップ 1

メインメニューから [管理（Administration）] > [データゲートウェイの管理（Data Gateway Management）] を選択し、[プール（Pools）] タブをクリックします。

ステップ 2

高可用性（HA）プールを編集します。

  1. このページに表示されるプールの一覧から編集するプールを選択します。

  2. [Edit] アイコン ボタンをクリックして、[高可用性（HA）プールの編集（Edit high availability (HA) pool] ページを開きます。

    リソースプールを編集する場合、[プールパラメータ（Pool parameters）] ペインの一部のパラメータのみを変更できます。残りのパラメータを変更するには、必要な値で新しいプールを作成し、データ ゲートウェイ インスタンスをそのプールに移動します。

    図 17. [データゲートウェイの管理（Data Gateway Management）] - [HAプールの編集（Edit HA Pool）] ウィンドウ
    [データゲートウェイの管理（Data Gateway Management）] - [HAプールの編集（Edit HA Pool）]

  3. [プールパラメータ（Pool parameters）] ペインでは、プールのタイプに応じて変化するリソースパラメータを変更できます。

    • 必要なアクティブ データ ゲートウェイごとに仮想 IP アドレスまたは FQDN を追加します。デュアルスタック展開の場合は、IPv4 アドレスと IPv6 アドレスの両方を指定します。

    • スタンバイ データ ゲートウェイ インスタンスの数を変更します。

    • データ ゲートウェイ インスタンスをプールから追加および削除します。

    • プールの FQDN を有効または無効にします。

  4. [アクティブ（Active）] および [スタンバイ（Standby）] のサイトパラメータペインで、データゲートウェイ VM の IP アドレスまたは FQDN アドレスを変更できます。[アクティブ（Active）] および [スタンバイ（Standby）] ペインは、Geo 冗長性機能が有効になっている場合にのみ表示されます。Geo 冗長性機能の詳細については、『Cisco Crosswork Network Controller 7.0 Installation Guide』の「Enable Geo Redundancy」セクションを参照してください。

  5. 変更が完了したら、[保存（Save）] をクリックします。

ステップ 3

データゲートウェイプールを削除します。

  1. 削除するプールを選択し、[Delete] アイコン をクリックします。

  2. [高可用性（HA）プールの削除（Delete high availability (HA) Pool] ウィンドウで [削除（Delete）] をクリックして、プールを削除します。

Crosswork Data Gateway デバイス割り当ての管理

Crosswork Data Gateway からデバイスを移動または切り離す場合は、次のガイドラインに従います。

  • デバイスは 1 つの Crosswork Data Gateway のみに接続できます。

  • デバイスを異なるプールの Crosswork Data Gateway に移動する場合は、移動先プールのゲートウェイが現在のプールのゲートウェイと同じであることを確認してください。ゲートウェイが一致しない Crosswork Data Gateway にデバイスを移動すると、収集が失敗します。

  • Crosswork Data Gateway からデバイスを切り離すと、そのデバイスに対応するすべての収集ジョブが削除されます。切り離すデバイスに送信された収集ジョブを失いたくない場合は、代わりに別のデータゲートウェイにデバイスを移動します。

Crosswork Data Gateway プールからデバイスを移動または切り離すには、次の手順に従います。プールにデバイスを追加するには、「Crosswork Data Gateway へのデバイスの接続」を参照してください。

手順

ステップ 1

Cisco Crosswork メインメニューから、[管理（Administration）] > [Data Gatewayの管理（Data Gateway Management）] > [データゲートウェイ（Data gateways）] に移動します。

図 18. [データゲートウェイ（Data Gateways）] ウィンドウ
[データゲートウェイ（Data Gateways）] ウィンドウ

ステップ 2

デバイスを移動するには、次の手順を実行します。

  1. デバイスを移動する Crosswork Data Gateway の [アクション（Actions）] 列で、[その他（More）] アイコン をクリックして [デバイスの移動（Move devices）] を選択します。[接続されているデバイスの移動（Move attached devices）] ウィンドウが開き、移動可能なすべてのデバイスが表示されます。

  2. [このデータゲートウェイに移動（To this data gateway）] ドロップダウンから、デバイスの移動先のデータゲートウェイを選択します。

  3. すべてのデバイスを移動するには、[すべてのデバイスを移動（Move all devices）] をクリックします。それ以外の場合は、移動するデバイスを選択し、[選択したデバイスの移動（Move selected devices）] をクリックします。

  4. [確認：デバイスの移動（Confirm - Move devices）] ウィンドウで、[移動（Move）] をクリックします。

ステップ 3

デバイスを切り離すには、次の手順を実行します。

  1. デバイスを切り離す Crosswork Data Gateway の [アクション（Actions）] 列で、[その他（More）] アイコン をクリックして [デバイスの切断（Detach devices）] を選択します。[デバイスの切断（Detach devices）] ウィンドウが開き、接続されているすべてのデバイスが表示されます。

    図 19. [デバイスの切断（Detach Devices）] ウィンドウ

  2. すべてのデバイスを切り離すには、[すべてのデバイスの切断（Detach all devices）] をクリックしますそれ以外の場合は、切り離すデバイスを選択し、[切断（Detach）] をクリックします。

  3. [確認：デバイスの切断（Confirm - Detach Devices）] ウィンドウで、[切断（Detach）] をクリックします。

[データゲートウェイ（Data gateways）] ペインの [接続デバイス数（Attached device count）] を確認して、変更が成功したことを確認します。接続デバイス数の横にある アイコンをクリックすると、選択した Crosswork Data Gateway に接続されているデバイスのリストが表示されます。

フェールオーバーを開始する方法については、手動フェールオーバーの実行を参照してください。

Crosswork Data Gateway インスタンスの維持

この項では、Crosswork Data Gateway インスタンスのメンテナンスタスクについて説明します。

Crosswork Data Gateway インスタンスの管理状態の変更

Crosswork プラットフォームと Crosswork Data Gateway 間の動作を一時停止するために、データセンター内でアップグレードまたはその他のメンテナンスを実行することが必要になる場合があります。これは、Crosswork Data Gateway を [メンテナンス（Maintenance）] モードにすることで実現できます。ダウンタイム時に、管理者は証明書の更新などの変更を、Crosswork Data Gateway に加えることができます。


（注）  

メンテナンスアクティビティが Crosswork と Crosswork Data Gateway の間の通信に影響を与えている場合は収集は中断され、通信が復元されると再開されます。同様に、メンテナンスアクティビティが Crosswork Data Gateway と外部接続先（Kafka/gRPC）間の通信に影響している場合は収集が相互に中断され、通信が復元されると再開されます。

変更が完了すると、管理者は管理状態を [アップ（Up）] に変更できます。Crosswork Data Gateway インスタンスが起動すると、Crosswork ネットワークコントローラ がジョブの送信を再開します。


（注）  

[割り当て済み（Assigned）] 状態では、データゲートウェイをメンテナンスモードに直接切り替えることはできません。メンテナンスモードにするには、スタンバイが使用可能なときに手動フェールオーバーを実行するか、プールからデータゲートウェイを削除する必要があります。手動フェールオーバーの詳細については、手動フェールオーバーの実行を参照してください。

Crosswork Data Gateway インスタンスの管理状態を変更するには、次の手順を実行します。

始める前に

ロールが割り当てられている場合は、データゲートウェイを [メンテナンス（Maintenance）] モードに移行できません。これは、データゲートウェイがプールでアクティブであることを示しています。ただし、ゲートウェイには次のロールを割り当てることができます。

  • 手動または自動フェールオーバーが発生した場合のスペアのロール。

  • プール内の唯一のゲートウェイである場合に割り当てられるロール。

手順

ステップ 1

メインメニューから、[管理（Administration）] > [データゲートウェイの管理（Data Gateway Management）] > [データゲートウェイインスタンス（Data gateway instances）] の順に選択します。

テーブル内のデータ ゲートウェイ インスタンスまたはプール名をクリックして、インスタンスの動作と正常性の概要を表示する Crosswork Data Gateway の詳細ページに移動することもできます。データ ゲートウェイ インスタンス名の横にある をクリックすると、インターフェイスロールの詳細を含む登録の詳細が表示されます。

ステップ 2

管理ステータスを変更する Crosswork Data Gateway の [アクション（Actions）] 列で [その他（More）] アイコン をクリックします。

図 20. [データゲートウェイインスタンス（Data Gateway Instances）] ウィンドウ
[データゲートウェイインスタンス（Data Gateway Instances）] ウィンドウ

ステップ 3

データ ゲートウェイ インスタンスに割り当てる管理状態を選択します。

Crosswork Data Gateway インスタンスを Crosswork ネットワークコントローラ から削除

Crosswork Data Gateway インスタンスを Crosswork ネットワークコントローラ から削除するには、次の手順を実行します。

始める前に

データゲートウェイの削除を検討するときは、削除プロセスが中断されないように次のガイドラインを確認してください。

  • 収集ジョブの損失を防ぐために、接続されているデバイスを代替のデータゲートウェイに移動します。Crosswork Data Gateway インスタンスからデバイスを切り離すと、対応するジョブが削除されます。

  • データ ゲートウェイ インスタンスがプールの一部である場合は、インスタンスが未割り当て状態であることを確認します。

手順

ステップ 1

メインメニューから、[管理（Administration）] > [データゲートウェイの管理（Data Gateway Management）] > [データゲートウェイインスタンス（Data gateway instances）] の順に選択します。

ステップ 2

削除する Crosswork Data Gateway の [アクション（Actions）] 列の下にある [その他（More）] アイコン をクリックし、[削除（Delete）] をクリックします。

図 21. [データゲートウェイインスタンス（Data Gateway Instances）] ウィンドウ
[データゲートウェイインスタンス（Data Gateway Instances）] ウィンドウ

ステップ 3

Crosswork Data Gateway インスタンスを削除するには、インスタンスがメンテナンスモードになっている必要があります。[メンテナンス（Maintenance）] モードに切り替えるように求められたら、[メンテナンスに切り替えて続行（Switch to maintenance & continue）] をクリックします。

図 22. [メンテナンスに切り替えて続行（Switch to maintenance & continue）] ポップアップウィンドウ
[メンテナンスに切り替え（Switch to Maintenance）] ポップアップウィンドウ

ステップ 4

[データゲートウェイの削除に関連する事項を理解しました（I understand the concern associated with deleting the Data Gateways）] のチェックボックスをオンにします。[CDGの削除（Remove CDG）] をクリックします。

図 23. [データゲートウェイの削除確認（Delete Data Gateway Confirmation）] ダイアログボックス
[データゲートウェイの削除確認（Delete Data Gateway Confirmation）] ダイアログボックス

Crosswork Data Gateway インスタンスの再展開

データ ゲートウェイ インスタンスを再展開するには、古いインスタンスを削除して新しいインスタンスをインストールします。新しいデータ ゲートウェイ インスタンスをインストールする方法の詳細については、『Cisco Crosswork Network Controller 7.0 Installation Guide』を参照してください』。

インスタンスの展開プロファイルを変更するためにデータ ゲートウェイ インスタンスを再展開する場合（たとえば、プロファイルを Standard から Extended に変更する場合）、データ ゲートウェイ インスタンスの再展開を試みる前に、データ ゲートウェイ グローバル パラメータの変更を手動でロールバックしてください。

考慮すべき重要な点

  • データ ゲートウェイ インスタンスがすでに Cisco Crosswork に登録されており、同じ名前でインスタンスを再度インストールした場合は、データ ゲートウェイ インスタンスの [管理状態（Administration state）] を [メンテナンス（Maintenance）] に変更して自動登録を実行します。

  • データ ゲートウェイ インスタンスがすでに Cisco Crosswork に登録されており、Cisco Crosswork を再度インストールした場合は、既存のデータ ゲートウェイ インスタンスを Cisco Crosswork に再登録します。Crosswork Data Gateway の再登録を参照してください。

  • 同じホスト名を持つデータ ゲートウェイ インスタンスを再展開する場合は、混乱を避けるために、そのホスト名の既存のアラームをクリアします。そうしないと、古いアラームが引き続き履歴に表示されます。古いアラームで、タイムスタンプを確認する必要があります。これは、古いデータゲートウェイで発生したのか、同じホスト名を持つ現在のデータゲートウェイで発生したのかを判断するために必要です。

Crosswork Data Gateway グローバル設定の設定

ここでは、Crosswork Data Gateway のグローバル設定を指定する方法について説明します。これらの設定は次のとおりです。

外部データ送信先の作成と管理

Cisco Crosswork では、収集ジョブでデータをデポジットするために使用できる外部データ送信先（Kafka または外部 gRPC）を作成できます。

これには、[管理（Administration）] > [データコレクターのグローバル設定（Data Collector(s) Global Settings）] > [データ送信先（Data destinations）] に移動してアクセスできます。新しいデータ送信先の追加、既存のデータ送信先の設定の更新、データ送信先の削除を行うことができます。

[データ送信先（Data destinations）] ページのテーブルには、データをデポジットするために収集ジョブで使用できる承認済みのデータ送信先のリストが表示されます。


（注）  

Crosswork_Kafka と cd-astack-pipeline は内部データ送信先であり、更新または削除はできません。

図 24. [データ送信先（Data Destinations）] ウィンドウ
[データ送信先（Data Destinations）] ウィンドウ

UUID は、データ送信先の一意の識別子です。Crosswork ネットワークコントローラ は、外部データ送信先が作成されると、この ID を自動的に生成します。Cisco Crosswork UI を使用して収集ジョブを作成する場合、設定済みの送信先のドロップダウンリストを使用してデータの送信先を選択します。API を介して収集ジョブを作成する場合、収集したデータをコレクターが送信する宛先の UUID を知る必要があります。

データ送信先の詳細を表示するには、[データ送信先（Data destinations）] ペインで、詳細を表示するデータ送信先名の横にある アイコンをクリックします。

外部収集ジョブのライセンス要件

データを外部のデータ送信先に転送できる収集ジョブを作成できるようにするには、次のライセンス要件を満たしていることを確認します。

  1. メインメニューから、[管理（Administration）] > [アプリケーション管理（Application Management）] > [スマートライセンス（Smart License）] に移動します。

  2. アプリケーションフィールドで [Crossworkプラットフォームサービス（Crosswork Platform Services）] を選択します。

  3. ステータスが次のようになっていることを確認します。

    • [登録ステータス（Registration Status ）]：[登録済み（Registered）]

      Cisco Smart Software Manager（CSSM）に登録済みであり、予約済みライセンス機能の使用が許可されていることを示します。

    • [ライセンス認証ステータス（License Authorization Status）]：[認証済み（Authorized）]（[準拠（In Compliance）]）

      外部収集ジョブのデバイス数を超えていないことを示します。

    • [スマートライセンスの使用状況（Smart Licensing Usage）] で、CW_EXTERNAL_COLLECT のステータスが [準拠（In Compliance）] になっています。

評価期間が終了した後、または外部収集ジョブのデバイス数を超えた場合（[ライセンス認証ステータス（License Authorization Status）] が [コンプライアンス違反（Out of Compliance）]）、Cisco Smart Software Manager（CSSM）に登録しないと、外部収集ジョブを作成できません。ただし、この場合も既存の収集ジョブは表示および削除できます。

データ宛先の追加または編集

新しいデータ送信先を追加するには、次の手順を実行します。その後、このデータ宛先を使用してデータを転送できます。複数のデータ送信先を追加することができます。

外部データの宛先を追加する際の注意点は次のとおりです。

  • 既存の外部 Kafka データの送信先を同じ IP アドレスで再インストールする場合は、コレクターを再起動して変更を有効にする必要があります。

  • Cisco Crosswork および指定したデータ送信先、つまり Crosswork Kafka または外部 Kafka のいずれかの間の通信チャネルをセキュリティで保護できます。（この手順の ステップ 6 に進みます）。ただし、セキュリティを有効にすると、パフォーマンスに影響する可能性があります。

  • 外部データ送信先で TLS 接続が必要な場合は、公開証明書を準備するか、クライアント認証が必要な場合は、クライアント証明書とキーファイルを準備します。クライアントキーはパスワードで暗号化されている可能性があり、データ送信先のプロビジョニングの一部として設定する必要があります。現在、Crosswork Data Gateway は IP ベースの証明書のみをサポートしています。

  • 認証局で証明書を生成する場合は、証明書が PEM でエンコードされ、キーファイルが PKCS＃8 形式であることを確認します。

  • Cisco Crosswork にジョブを送信する前に、Kafka トピックを作成してください。外部 Kafka とその外部 Kafka でのトピックの管理方法によっては、収集されたデータをその特定の外部 Kafka/トピックにディスパッチするときにトピックが存在しない場合、Cisco Crosswork ログに次の例外が表示されます。これは、トピックがまだ作成されていないか、収集ジョブが完了する前にトピックが削除されたことが原因である可能性があります。 

    destinationContext: topicmdt4
org.apache.kafka.common.errors.UnknownTopicOrPartitionException: This server does not host this topic-partition.

  • データ宛先のポート接続を確認して検証します。宛先でポートに到達できない場合、収集が失敗します。

  • Crosswork Data Gateway では、Kafka 宛先の宛先プロパティでカスタム値を設定できます（この手順のステップ 4 を参照）。


    （注）  

    この機能は、gRPC 宛先ではサポートされていません。

  • [宛先の詳細（Destination Details）] ペインに入力されたグローバルプロパティは必須であり、個々のコレクターレベルでカスタム値が指定されていない限り、デフォルトで Kafka 宛先に適用されます。コレクターに指定するカスタム値は、そのコレクターにのみ適用されます。

  • Crosswork Data Gateway の展開時に指定されたプロトコルに応じて、外部宛先は IPv4 または IPv6 である必要があります。たとえば、展開中に IPv4 が選択された場合、外部宛先も IPv4 である必要があります。

  • ホスト名と IP アドレスマッピングの変更は、DNS サーバーの [存続可能時間（TTL）（Time to Live (TTL)）] フィールドで構成された期間が完了した後にのみ、Crosswork Data Gateway に反映されます。変更をすぐに反映させたい場合は、VM を再起動することをお勧めします。

始める前に

データ収集に外部 Kafka サーバーを使用している場合は、次のことを確認します。

  • 外部 Kafka サーバーで次のプロパティを設定した。


    （注）  

    これらのプロパティの説明と使用方法については、Kafka のドキュメントを参照してください。この説明はこのドキュメントの対象範囲外です。

    • num.io.threads = 8

    • num.network.threads = 3

    • message.max.bytes= 30000000

  • データ収集に使用する Kafkaトピックを作成している。

  • 新規の収集ジョブを開始する前に、「reachability-topic」がこの Kafka 接続先に設定されていることを確認します。この構成は、Kafka 接続先の正常性を監視するために必要です。

手順

ステップ 1

メインメニューから、[管理（Administration）] > [データコレクターのグローバル設定（Data Collector(s) Global Settings）] > [データ送信先（Data destinations）] を選択します。

ステップ 2

[データ送信先（Data destinations）] ページで、[追加（Add）] アイコン ボタンをクリックします。[接続先の追加（Add destination）] ページが開きます。

既存の接続先を編集する場合は、[Edit] アイコン ボタンをクリックして [接続先の編集（Edit destination）] ページを開き、パラメータを編集します。

（注）  

 

データ送信先を更新すると、Crosswork Data Gateway はその更新内容を使用して、そのデータ送信先とのセッションを再確立します。データ収集は一時停止され、セッションが再確立されると再開されます。

ステップ 3

次のパラメータの値を入力するか、または変更します。

フィールド 値 利用可能

gRPC

 利用可能

Kafka

宛先名（Destination name）

わかりやすいデータ送信先名を入力します。名前には、最大 128 文字の英数字と、アンダースコア（「_」）、またはハイフン（「-」）を含めることができます。その他の特殊文字は使用できません。

多数のデータ送信先がある場合は、後で識別できるように、できるだけわかりやすい名前にします。

対応

対応

サーバータイプ（Server type）

ドロップダウンから、データ送信先のサーバータイプを選択します。

対応

対応

エンコードタイプ（Encoding type）

ドロップダウンから、エンコーディング（json または gpbkv）を選択します。

対応

対応

圧縮タイプ（Compression yype）

ドロップダウンから、圧縮タイプを選択します。

対応

サポートされている圧縮タイプは、snappy、gzip、および deflate です。

対応

サポートされている圧縮タイプは、snappy、gzip、lz4、zstd、および none です。

（注）  

 

zstd 圧縮タイプは、Kafka 2.0 以降でのみサポートされています。

ディスパッチの種類（Dispatch Type）

このフィールドは、[サーバータイプ（Server Type）] フィールドが gRPC に設定されている場合に使用できます。

ドロップダウンから、ディスパッチ方法としてストリームまたは単項を選択します。

Crosswork Data Gateway は、収集したデータをデータストリームまたは単項として宛先に送信します。デフォルト値は、単項です。

対応

非対応

最大メッセージサイズ（バイト単位）（Maximum message size (bytes)）

最大メッセージサイズを入力します（バイト単位）。

  • デフォルト値：100000000 バイト/100 MB

  • 最小：1000000 バイト/1 MB

  • 最大：100000000 バイト/100 MB

非対応

対応

バッファメモリ（Buffer memory）

必要なバッファメモリをバイト単位で入力します。

  • デフォルト値：52428800 バイト

  • 最小：52428800 バイト

  • 最大：314572800 バイト

非対応

対応

バッチサイズ（バイト単位）（Batch size (bytes)）

必要なバッチサイズを入力します（バイト単位）。

  • デフォルト値：1048576 バイト/1.048576 MB

  • 最小：16384 バイト/16.38 KB

  • 最大：6400000 バイト/6.4 MB

非対応

対応

リンガー（ミリ秒）（Linger (milliseconds)）

必要なリンガー時間を入力します（ミリ秒単位）。

  • デフォルト値：2000 ミリ秒

  • 最小：0 ms

  • 最大：5000 ms

非対応

対応

要求のタイムアウト（Request Timeout）

要求が応答を待機する時間を入力します。構成された時間が経過すると、要求は期限切れになります。

  • デフォルト値：30 ミリ秒

  • 最小：30 ミリ秒

  • 最大：60 ミリ秒

対応

対応

テレメトリベースの収集の場合は、最適な結果を得るために、[バッチサイズ（Batch size）] を 16,384 バイト、[リンガー（Linger）] を 500 ミリ秒に設定することをお勧めします。

ステップ 4

（オプション）Kafka 接続先のグローバルプロパティとは異なるカスタム値を設定するには、[コレクター: 個別のコレクタープロパティ（Collectors - Per collector properties）] ペインで、次の操作を行います。

  1. [コレクター（Collector）] を選択します。

  2. 以下のフィールドに値を入力します。

    • [カスタムバッファメモリ（Custom buffer memory）]

    • [カスタムバッチサイズ（Custom batch size）]

      （注）  

       
      [カスタムバッチサイズ（Custom batch size）] は、 [カスタムバッファメモリ（Custom buffer memory）] の実行時の値を超えることはできません。[カスタムバッファメモリ（Custom buffer memory）] フィールドに値を指定しない場合、[カスタムバッチサイズ（Custom batch size）] は [バッファメモリ（Buffer memory）] フィールドの値に対して検証されます。

    • [カスタムリンガー（Custom linger）]

    • [カスタム要求タイムアウト（Custom request timeout）]

    図 25. [接続先の追加（Add Destination）] ウィンドウ
    [接続先の追加（Add Destination）] ウィンドウ

  3. [+もう1つ追加する（+ Add another）] をクリックしてこの手順を繰り返し、別のコレクターのカスタム設定を追加します。

（注）  

 
ここで入力した個々のコレクターのプロパティは、ステップ 3 で入力したグローバル設定よりも優先されます。ここでフィールドに値を入力しない場合、同じ値はステップ 3 で入力したグローバルプロパティから取得されます。

ステップ 5

[接続の詳細（Connection details）] オプションから TCP/IP スタックを選択します。サポートされているプロトコルは、IPv4、IPv6、デュアルスタックおよび FQDN です。

（注）  

 

FQDN アドレスは、Kafka 接続先に対してのみサポートされます。

ステップ 6

次の表に従って [接続の詳細（Connection details）] フィールドに入力します。表示されるフィールドは、選択した接続タイプによって異なります。入力する値は、外部 Kafka または gRPC サーバーで設定されている値と一致する必要があります。

（注）  

 

ユーザーが定義した接続先のポート番号のみを変更できます。システムで作成された接続先のポート番号は変更できません。
接続タイプ フィールド

gRPC で利用可能

Kafka で利用可能

IPv4

必須の [IPv4アドレス/サブネットマスク（IPv4 address/Subnet mask）] と [ポート（Port）] に入力します。[+ もう 1 つ追加する（+ Add another）] をクリックして、複数の IPv4 アドレスを追加できます。

IPv4 サブネットマスクの範囲は 1 〜 32、ポートの範囲は 1024 〜 65535 です。

対応

対応

IPv6

必須の [IPv6アドレス/サブネットマスク（IPv6 address/Subnet mask）] と [ポート（Port）] に入力します。[+ もう 1 つ追加する（+ Add another）] をクリックして、複数の IPv6 アドレスを追加できます。

IPv4 サブネットマスクの範囲は 1 〜 32、ポートの範囲は 1024 〜 65535 です。

IPv6 サブネットマスクの範囲は 1 〜 128、ポートの範囲は 1024 〜 65535 です。

対応

対応

デュアル スタック

[IPv4アドレス/サブネットマスク（IPv4 address/Subnet mask）]、[IPv6アドレス/サブネットマスク（IPv6 address/Subnet mask）] および [ポート（Port）] に入力します。[+ もう 1 つ追加する（+ Add another）] をクリックして、複数のアドレスを追加できます。

対応

対応

FQDN

必須の [ホスト名（Host name）]、[ドメイン名（Domain name）]、および [ポート（Port）] を入力します。サポートされるポートの範囲は 1024 ～ 65535 です。

[+もう1つ追加する（+ Add another）] をクリックして、複数の FQDN アドレスを追加できます。

対応

対応

IP とポート（または FQDN とポート）の接続の詳細が既存の接続先と一致する場合は、重複する接続先を作成することの確認メッセージが表示されます。

ステップ 7

（オプション）Kafka または gRPC ベースのデータ送信先に安全に接続するには、[セキュリティの詳細（Security details）] スライダを移動して [セキュア通信の有効化（Enable secure communication）] オプションを有効にします。

ステップ 8

Kafka または gRPC ベースのデータ送信先の場合、次のいずれかを選択して、認証プロセスのタイプを選択します。

  • 相互認証（Mutual-Auth）：CA 証明書の後に外部サーバーと Crosswork Data Gateway コレクターを認証し、中間証明書またはキーが Crosswork UI にアップロードされます。

  • サーバー認証（Server-Auth）：CA 証明書を Crosswork UI にアップロードしてから、外部サーバーと Crosswork Data Gateway コレクターを認証します。[サーバー認証（Server-Auth）] がデフォルトの認証プロセスです。

（注）  

 

認証オプションは、[セキュア通信の有効化（Enable secure communication）] が有効になっている場合にのみ使用できます。

ステップ 9

[保存（Save）] をクリックします。

次のタスク
[セキュア通信の有効化（Enable secure communication）] オプションを有効にした場合は、Cisco Crosswork UI（[管理（Administration）] > [証明書の管理（Certificate Management）]）に移動し、新たに追加したデータ送信先に関連する証明書を追加します。この手順は、デバイスとのセキュアな通信を確立するには必須です。詳細については、証明書の管理を参照してください。

（注）  

[セキュア通信の有効化（Enable secure communication）] オプションを有効にした後、データ送信先の証明書を追加していない、または証明書が不完全である場合、Cisco Crosswork は接続先をエラー状態に設定します。接続先がエラー状態の場合、収集ジョブのステータスは低下します。

データ送信先の削除

データ送信先を削除するには、次の手順を実行します。

始める前に
データ送信先は、どの収集ジョブにも関連付けられていない場合にのみ削除できます。[収集ジョブ（Collection Jobs）] ビューで、データ送信先を使用している収集ジョブがあるかどうかを確認することをお勧めします。
手順

ステップ 1

メインメニューから、[管理（Administration）] > [データゲートウェイのグローバル設定（Data Gateway Global Settings）] > [データ送信先（Data destinations）] を選択します。

ステップ 2

表示された宛先一覧から削除したいデータ宛先を選択し、[Delete] アイコン ボタンをクリックします。

ステップ 3

[データ送信先の削除（Delete data destination(s)）] ポップアップで、[削除（Delete）] をクリックして確認します。

デバイス パッケージ

デバイス管理により、Crosswork Data Gateway は、デバイスパッケージを介してデータ収集機能をシスコのアプリケーションとサードパーティデバイスに拡張できます。Crosswork Data Gateway は、システムおよびカスタムデバイスパッケージをサポートします。

システムデバイスと MIB パッケージは、Crosswork ソフトウェアにバンドルされており、システムインスタンスに自動的にダウンロードされます。システムデバイスと MIB パッケージは変更できません。カスタムデバイスパッケージは、デバイスの対象範囲と収集機能をサードパーティデバイスに拡張します。Crosswork が提供するデフォルトパッケージが環境に適していないとします。つまり、サードパーティ製デバイスからデータを収集する必要がある場合や、デフォルトの MIB パッケージがサポートしていない特定のデータが必要な場合などです。その場合は、パッケージをカスタマイズして Crosswork にアップロードします。パッケージのカスタマイズについては、シスコまたはシスコパートナーにお問い合わせください。

カスタムパッケージ

次の 3 つのタイプのカスタムパッケージを Cisco Crosswork にアップロードできます。

  1. CLI デバイスパッケージ：CLI ベースの KPI を使用して、サードパーティ製デバイスのデバイス正常性をモニターします。すべてのカスタム CLI デバイスパッケージは、対応する YANG モデルとともにファイル custom-cli-device-packages.tar.xz に含まれている必要があります。複数のファイルをサポートできます。ただし、デバイスごとに異なるファイルを 1 つのパッケージにバンドルする場合は、集約パッケージを使用できます。

  2. カスタム MIB パッケージ：カスタム MIB およびデバイスパッケージは、サードパーティ製デバイスに固有であるか、または収集されたデータをフィルタ処理したり、シスコデバイス用に異なる形式にしたりするために使用できます。これらのパッケージは編集できます。すべてのカスタム SNMP MIB パッケージは、YANG モデルとともにファイル custom-mib-packages.tar.xz に含める必要があります。複数のファイルをサポートできます。


    （注）  

    Crosswork Data Gateway は、システムにすでに含まれている標準的な MIB について、サードパーティ製デバイスで SNMP ポーリングを有効にします。独自の MIB は、収集要求が独自の MIB から MIB テーブル名またはスカラー名を参照する場合にのみ必要です。ただし、要求が OID ベースの場合、MIB は必要ありません。

  3. SNMP デバイスパッケージ：Crosswork Data Gateway では、必要な MIB と YANG の説明を追加したカスタム SNMP デバイスパッケージをアップロードすることで、SNMP カバレッジを拡張できます。

  4. 集約パッケージ：集約パッケージオプションを使用すると、サポートされている複数のファイル拡張子を 1 つのパッケージに含めることができます。これらのファイルは、コレクターおよびアプリケーション固有のファイルにすることができます。たとえば、集約パッケージは、CLI および SNMP デバイスパッケージのファイルで構成できます。

    Crosswork UI では、これらのパッケージをアップロードまたはダウンロードできます。各パッケージには、次の拡張子を持つ 1 つまたは複数のファイルを含めることができます。

    コレクターファイル：

    • YANG（.yang）

    • MIB（.mib、.my）

    • 定義（.def）

    • デバイス パッケージ（.xar）

    アプリケーションファイル：

    • デバイスメタデータ（.yaml、.yml）

    • Zips（.zip）

    • SDU バンドル（.sdu）

カスタムパッケージを追加するためのワークフロー

このワークフローを使用して、シスコ以外のデバイス用のカスタムパッケージを追加する方法を習得します。

  1. サポートするデバイスの YANG モデルファイルをベンダーから取得します。

  2. ファイルを common/ ディレクトリに保存します。

  3. ディレクトリを tar ファイルにして、単一のカスタムパッケージを作成します。

  4. そのファイルを Crosswork Network Controller にロードまたは追加します。


（注）  

Crosswork Network Controller は一度に 1 つのファイルのみをロードできます。2 つのファイルを含むパッケージをロードし、3 番目のタイプのデバイスのサポートを追加する必要がある場合は、ファイルを common ディレクトリに追加し、アップロードする 3 つのファイルすべてを含む置換ファイルを作成します。

カスタムパッケージの追加

これは、Cisco Crosswork へのパッケージのアップロードに関するガイドラインのリストです。

  1. カスタム CLI デバイスパッケージを更新するには、[カスタムパッケージ（Custom packages）] ページのファイル名の横にあるアップロードアイコンをクリックします。カスタムパッケージを更新すると、既存のファイルが置き換えられます。

  2. 複数の xar ファイルをアップロードするには、それらを単一の tar.gz パッケージにバンドルします。

  3. Crosswork ネットワークコントローラ では、カスタム MIB パッケージファイルでシステム MIB パッケージファイルを上書きすることはできません。その結果、アップロード試行が失敗します。

  4. カスタムパッケージの TAR ファイルに含まれているのはパッケージフォルダのみであり、TAR ファイルの一部として親フォルダまたはフォルダの階層が含まれていないことを確認します。正しくインポートされなかった場合、Crosswork ネットワークコントローラ はカスタムパッケージでジョブを実行すると例外をスローします。


    （注）  

    Crosswork ネットワークコントローラ は、ファイル拡張子をチェックする以外に、アップロードされるファイルを検証しません。

次の手順を実行してカスタム ソフトウェア パッケージをアップロードします。

始める前に

  • カスタム MIB パッケージの一部として新しい MIB をアップロードする場合は、それらの新しい MIB ファイルを既存のシステム MIB ファイルとともにコレクター内にアップロードできることを確認します。これにより、ファイル内のすべての依存関係が適切に解決されます。

  • 集約パッケージを追加する場合は、以下の点を確認してください。

    • パッケージには、サポートされているファイル拡張子のみが含まれている必要があります。サポートされている拡張機能のリストについては、カスタムパッケージを参照してください。

    • ファイルのバンドルは、.tar.gz 形式のみで行う必要があります。

    • 最上位ディレクトリには、次の指定されたコレクタータイプが少なくとも 1 つ含まれている必要があります。

      • snmp

      • cli

      • common

    ディレクトリ構造の例

    
├── cli
│   ├── defs
│   │   └── cli-def1.def
│   ├── device-metadata
│   │   ├── cli.yml
│   │   └── cli-device-metadata.yaml
│   ├── zips
│   │   └── cli-zip.zip
│   ├── sdus
|   │   └── cli-sdu.sdu
│   ├── xars
│   │   ├── cli-xar1.xar
│   │   └── cli-xar2.xar
│   └── yangs
│       ├── cli-yang1.yang
│       └── cli-yang2.yang
├── common
│   ├── defs
│   │   └── common-def1.def
│   ├── device-metadata
│   │   ├── common.yml
│   │   └── common-device-metadata.yaml
│   ├── zips
│   │   └── common-zip.zip
│   ├── mibs
│   │   ├── common-mib1.mib
│   │   └── common-mib2.my
│   ├── sdus
|   │   └── common-sdu.sdu
│   ├── xars
│   │   ├── common-xar1.xar
│   │   └── common-xar2.xar
│   └── yangs
│       ├── common-yang1.yang
│       └── common-yang2.yang
└── snmp
    ├── defs
    │   └── snmp-def1.def
    ├── device-metadata
    │   ├── snmp.yml
    │   └── snmp-device-metadata.yaml
    ├── mibs
    │   ├── snmp-mib1.mib
    │   └── snmp-mib2.my
    ├── sdus
    │   └── snmp-sdu.sdu
    ├── zips
    │   └── snmp-zip.zip
    ├── xars
    │   ├── snmp-xar1.xar
    │   └── snmp-xar2.xar
    └── yangs
        ├── snmp-yang1.yang
        └── snmp-yang2.yang

  • 集約パッケージをアップロードすると、 cli/ および snmp/ ディレクトリにあるファイルに、CLI および SNMP コレクターからアクセスできます。また、 common/ ディレクトリ内のファイルには、CLI と SNMP の両方からアクセスできます。


（注）  
カスタムパッケージを実行する収集ジョブのパフォーマンスは、カスタムパッケージがどの程度最適化されているかによって異なります。Cisco Crosswork にアップロードする前に、パッケージが展開したい規模に最適化されていることを確認してください。

カスタム MIB と YANG を検証する方法、つまり、それらが Crosswork ネットワークコントローラ にアップロードできるかどうかを確認する方法については、『Use Custom MIBs and Yangs on Cisco DevNet』を参照してください。

手順

ステップ 1

メインメニューから、[管理（Administration）] > [データコレクターのグローバル設定（Data Collector(s) Global Settings）] > [カスタムパッケージ（Custom packages）] を選択します。

ステップ 2

[カスタムパッケージ（Custom packages）] ペインで、[追加（Add）] アイコン をクリックします。

ステップ 3

表示される [カスタムパッケージの追加（Add custom package）] ウィンドウで、インポートするパッケージのタイプを [タイプ（Type）] ドロップダウンから選択します。

ステップ 4

[ファイル名（File name）] の空白フィールドをクリックしてファイルブラウザウィンドウを開き、インポートするパッケージを選択して [開く（Open）] をクリックします。

ステップ 5

[メモ（Notes）] フィールドにパッケージの説明を追加します。パッケージを簡単に区別できるように、各パッケージに一意の説明を含めることをお勧めします。

ステップ 6

[アップロード（Upload）] をクリックします。

次のタスク
影響を受けたすべてのサービスを再起動して、最新のカスタム MIB パッケージの更新を取得します。
カスタムパッケージの削除

カスタムパッケージを削除すると、すべての YANG ファイルと XAR ファイルが Cisco Crosswork から削除されます。これは、カスタムパッケージを使用するすべての収集ジョブに影響します。

カスタムパッケージを削除するには、次の手順に従います。

手順

ステップ 1

メインメニューから、[管理（Administration）] > [データコレクターのグローバル設定（Data Collector(s) Global Settings）][カスタムパッケージ（Custom packages）] を選択します。

ステップ 2

[カスタムパッケージ（Custom packages）] ペインに表示されているリストから、削除するパッケージを選択して [Delete] アイコン をクリックします。

ステップ 3

表示された [カスタムパッケージの削除（Delete custom package）] ウィンドウで、[削除（Delete）] をクリックして確認します。

システムデバイスパッケージ

システムデバイスパッケージには、1 つ以上の個別のインストール可能ファイルが含まれています。パッケージ内の各ファイルセットは、同じアプリケーションに属します。

システムデバイスパッケージは、アプリケーション固有のマニフェストファイルを通じて単純な JSON ファイルとして提供されます。アプリケーションがインストールまたは更新されるたびに、システムデバイスパッケージが追加または更新されます。アプリケーションは、複数のデバイスパッケージをインストールできます。


重要

管理者は、システムデバイスパッケージを変更できません。これらのファイルを変更できるのは、アプリケーションのみです。システムデバイスパッケージを変更するには、シスコ カスタマー エクスペリエンス チームにお問い合わせください。
図 26. [システムデバイスパッケージ（System Device Packages）] ウィンドウ
[システムデバイスパッケージ（System Device Packages）] ウィンドウ

デバイスパッケージをダウンロードするには、[ファイル名（File name）] 列の名前の横にある ダウンロード アイコン ボタンをクリックします。

Crosswork Data Gateway グローバルパラメータの設定

Crosswork Data Gateway を使用すると、ネットワーク内のすべての Crosswork Data Gateway で次のパラメータを更新できます。


（注）  
これらの設定には、管理者ユーザーのみがアクセスできます。

手順

ステップ 1

[管理（Administration）] > [データコレクターのグローバル設定（Data Collector(s) Global Settings）] > [グローバルパラメータ（Global parameters）] に移動します。

図 27. [グローバルパラメータ（Global Parameters）] ウィンドウ
[グローバルパラメータ（Global Parameters）] ウィンドウ

ステップ 2

必要に応じて、1 つ以上のグローバルパラメータを変更します。

ポート値を適切に更新するには、次の点に留意してください。

  • 更新するポート値が有効なポートであることを確認します。

  • 新しいポートの値が Crosswork Data Gateway で構成されている既存のポート値と競合しないことを確認してください。

  • デバイス上で同じポート値を設定してください。

パラメータ名

説明

クラスタ VM 展開のデフォルト値
CLI セッションの数（Number of CLI sessions）

Crosswork Data Gateway とデバイス間の CLI セッションの最大数。

（注）  

 
この値は、同じパラメータに設定されている内部構成をオーバーライドします。

3

許容範囲は 1 ～ 50 です
SSHセッションタイムアウト（SSH session timeout）

セッションタイムアウト（秒）は、CLI および SNMP コレクターで CLI 接続がアイドル状態を維持できる時間です。

120

許容範囲は 1 ～ 120 秒です
SNMP トラップ ポート（SNMP trap port） 展開環境および構成要件に従って、この値を変更する必要があります。

1062

許容範囲は 1 ～ 65535 です
Syslog UDPポート（Syslog UDP port） 展開環境および構成要件に従って、この値を変更する必要があります。

9514

許容範囲は 1 ～ 65535 です
[Syslog TCPポート（Syslog TCP port）] -

9898

許容範囲は 1 ～ 65535 です
Syslog TLCポート（Syslog TLC port） -

6514

許容範囲は 1 ～ 65535 です
SNMPv3の詳細の再同期（Re-Sync SNMPv3 details）

USM の詳細は、デバイスが再起動または再イメージ化されるたびに変更されます。SNMPV3 コレクションは、USM の詳細のいずれかが変更されるたびに機能を停止します。

このオプションを有効にすると、最初の収集が失敗した後、変更があるたびに USM の詳細が自動的に同期されます。

無効

ステップ 3

ポートを更新する場合は、表示される [グローバルパラメータ（Global Parameters）] ウィンドウで [はい（Yes）] を選択して、コレクターを再起動できることを確認します。ポートを更新すると、コレクターは再起動し、実行中の収集ジョブを一時停止します。再起動が完了すると、ジョブは自動的に再開されます。

ステップ 4

[保存（save）] をクリックして変更を適用します。

ネットワーク内の Crosswork Data Gateway でのパラメータの更新が成功したかどうかを示すウィンドウが表示されます。

  1. すべての Crosswork Data Gateway が正常に更新された場合、更新が成功したことを示す成功メッセージが UI に表示されます。

  2. ネットワーク内の Crosswork Data Gateways のいずれかを更新できなかった場合、UI にエラーウィンドウが表示されます。Crosswork Data Gateway は、復旧中に障害が発生した Crosswork Data Gateway のパラメータを自動的に更新しようとします。一部のコレクターは、リカバリの一環として再始動される場合があります。


    （注）  

    Crosswork Data Gateway でグローバルパラメータの更新に失敗する理由の 1 つは、OAM チャネルがダウンしている可能性があります。OAM チャネルが再確立された後、Crosswork Data Gateway はこれらのパラメータを Crosswork Data Gateway に再度送信しようとし（同期していません）、既存の値と比較した後に値を更新します。

次のタスク

いずれかのポートを更新した場合は、[管理（Administration）] > [データゲートウェイの管理（Data Gateway Management）] > [データゲートウェイ（Data gateways）] タブに移動し、すべての Crosswork Data Gateway の [動作状態（Operational state）] が [アップ（Up）] になっていることを確認します。

Crosswork Data Gateway リソースの割り当て

Crosswork Data Gateway を使用すると、コレクターサービスの実行時にメモリをダイナミックに設定して割り当てることができます。使用頻度の高いコレクターにさらに多くのメモリを割り当てたり、UI からリソースのバランスを調整したりできます。


（注）  
これらの設定には、管理者ユーザーのみがアクセスできます。

このページには、コレクターサービス用に現在設定されているメモリが表示されます。メモリ値に加えた変更は、現在登録済みおよび将来の Crosswork Data Gateway に適用されます。


（注）  
このページに表示されるコレクターのリストは動的です。つまり、展開に固有です。

コレクターのリソース割り当てを更新するには、次の手順を実行します：


（注）  
Cisco Customer Experience（CX）チームと協力していない限り、これらの設定を変更しないことをお勧めします。
手順

ステップ 1

コレクターのリストと、コレクターごとに消費されたリソースがここに表示されます。

図 28. [リソースの構成（Resource configuration）] ウィンドウ
[リソース（Resource）] ウィンドウ

（注）  

 

NETCONF データ収集のサポートは、 Crosswork Network Controller 6.0 リリース以降では廃止されています。

ステップ 2

メモリ割り当てを変更するコレクターの [メモリ（Memory）] フィールドに、更新された値を入力します。

注目

 

CLI および SNMP コレクターには 2000 MB の最小メモリサイズをお勧めします。

ステップ 3

対応するコレクターのデータ収集を有効にするには、[コレクターの有効化（Enable collector）] チェックボックスをオンにします。

ステップ 4

変更が完了したら、[保存（Save）] をクリックします。

コレクターの値を更新すると、コレクターが再起動し、実行中の収集ジョブが一時停止します。再起動が完了すると、ジョブは自動的に再開されます。
コレクターの有効化または無効化

Crosswork Data Gateway は、データ収集を有効にすると、構成されたコレクターを介してデータの収集を開始し、無効にするまで継続します。リソースを最適化するために、またはデータ収集に影響を与えるコレクターに問題がある場合は、コレクターサービスを無効にすることができます。

コレクターを有効または無効にするには：

始める前に

コレクターを有効または無効にする前に、次の情報を確認してください。

  • SNMP および CLI コレクター（コンテナ）のデータ収集を無効にすることはできません。これらのコレクターは、デバイスの到達可能性を確認するために必要です。

  • デフォルトでは、コレクターは有効な状態になっています。


注目

コレクターは、Day 0 または Day 1 の構成中にのみ無効にする必要があります。Day 1 の後にコレクターを無効にする予定の場合、管理者は関連する収集ジョブを手動でクリアする必要があります。
手順

ステップ 1

[管理（Administration）]、[データコレクターのグローバル設定（Data Collector(s) Global Settings）]、[リソースの構成（Resource configuration）] に移動します。

コレクターのリストとリソース制限が表示されます。

図 29. コレクターの有効化または無効化

（注）  

 

NETCONF データ収集のサポートは、 Crosswork Network Controller 6.0 リリース以降では廃止されています。

ステップ 2

対応するコレクターのデータ収集を有効にするには、[コレクターの有効化（Enable collector）] チェックボックスをオンにします。データ収集を無効にするには、チェックボックスをオフにします。

ステップ 3

[保存（save）] をクリックして変更を適用します。

データ収集を有効にしたら、コレクターサービスのメモリ使用率を設定できます。リソース割り当ての詳細については、「Data Gateway Dynamic Resource Allocation」を参照してください。

Crosswork Data Gateway の収集ジョブ

収集ジョブは、Crosswork Data Gateway での実行が想定されているタスクです。アプリケーションは、収集ジョブを介してデータ収集を要求します。次に、Cisco Crosswork はこれらの収集ジョブを Crosswork Data Gateway に割り当てて、要求に対応できるようにします。

Crosswork Data Gateway は、CLI、MDT、SNMP、gNMI（ダイヤルイン）、syslog などの複数のデータ収集プロトコルをサポートしています。


（注）  

NETCONF データ収集のサポートは、 Crosswork Network Controller 6.0 リリース以降では廃止されています。

サポートされているプロトコルのいずれかを介して転送可能である限り、Crosswork Data Gateway ではどのようなタイプのデータでも収集できます。

Cisco Crosswork には、次の 2 種類のデータ収集要求があります。

  1. Crosswork 内の内部プロセス用にデータを転送するためのデータ収集要求。Cisco Crosswork は、この目的のためにシステムジョブを作成します。データゲートウェイでシスコ以外のデバイスから特定の情報を収集するには、カスタムデバイスパッケージを使用する必要があります。カスタムデバイスパッケージの詳細については、カスタムパッケージを参照してください。

    Crosswork が Crosswork 以外のデバイスと通信できるようにするモデルを構築する方法については、 Cisco Devnet を参照してください。

  2. 外部データの送信先にデータを転送するためのデータ収集要求。外部データの送信先（Kafka または gRPC）の構成の詳細については、外部データ送信先の作成と管理を参照してください。

KPI プロファイルの作成時に外部データ送信先を追加することにより、単一の収集要求で、収集されたデータを外部データ送信先と Cisco Crosswork Health Insights に転送できます。詳細については、『Cisco Crosswork Change Automation and Health Insights 4.3 User Guide』の「Create a New KPI Profile」の項を参照してください。


（注）  

Crosswork Data Gateway は、対応する（リスニング）収集ジョブの要求がない場合は着信トラフィックをドロップします。また、未承認デバイス（つまり、Crosswork Data Gateway に接続されていないデバイス）から受信したデータ、syslog イベント、および SNMP トラップもドロップします。

[収集ジョブ（Collection Jobs）] ページから、Crosswork ネットワークコントローラ に登録されているすべてのデータ ゲートウェイ インスタンスで現在アクティブな収集ジョブを表示できます。

Cisco Crosswork の UI の左側のナビゲーションバーで、[管理（Administration）] > [収集ジョブ（Collection Jobs）] を選択します。

[収集ジョブ（Collection Jobs）] ページの左側のペインには、[一括ジョブ（Bulk Jobs）] と [パラメータ化されたジョブ（Parametrized Jobs）] の 2 つのタブがあります。[一括ジョブ（Bulk Jobs）] には、システムによって、または UI および API から作成されたすべての収集ジョブが一覧表示されます。[パラメータ化されたジョブ（Parametrized Jobs）] ペインには、Service Health アプリケーションによって作成されたすべてのアクティブな CLI および gNMI ジョブが一覧表示されます。

詳細については、収集ジョブのモニターを参照してください。

収集ジョブのタイプ

Crosswork の UI（CLI）から、または API を使用して、次のタイプの収集ジョブを作成し、データを要求できます。

作成した収集ジョブごとに、Cisco Crosswork Data Gateway は収集要求を実行し、収集したデータを指定されたデータ送信先に転送します。

この章では、Cisco Crosswork の UI から収集ジョブを作成する方法について説明します。API を使用して収集ジョブを作成するには、『Crosswork Data Gateway APIs on Cisco Devnet』を参照してください。

Crosswork の UI のすべての収集ジョブの初期ステータスは [不明（Unknown）] です。収集ジョブを受信すると、Crosswork Data Gateway は基本的な検証を実行します。収集ジョブが有効な場合、そのステータスは [成功（Successful）] に変わります。それ以外の場合は [失敗（Failed）] に変わります。

[パターン（Cadence）] の値により、データゲートウェイがデバイスからデータを収集する頻度が決定します。頻度は 10 ～ 604800000 ミリ秒の範囲で設定できます。パターンは最小で 60 秒にすることをお勧めします。

パターンを設定するときは、デバイス内のデータが変更される頻度と、データが運用上重要かどうかを考慮してください。メモリ消費量や CPU 使用率などの一貫性のあるデータには、パターンの値を大きくすることをお勧めします。より動的なデータポイントについては、短いパターンを設定します。データゲートウェイが短いパターンで多くのテレメトリとより広範なデータセットを収集する必要がある場合、デバイスと Crosswork Network Controller に追加の負荷がかかります。これらの負荷をモデル化することは難しいため、最適な運用上の洞察と最も重要な実用的な情報が得られる値を見つけるために実際に試してみることをお勧めします。


（注）  

前の実行がまだ進行中であるためにデバイスからの収集がスキップされると、Crosswork Data Gateway は警告ログを生成します。このシナリオではアラートは生成されません。

CLI 収集ジョブ

Crosswork Data Gateway は、次のコマンドを使用したネットワークデバイスからの CLI ベースのデータ収集をサポートしています。

  • show と、短縮バージョンの sh

  • traceroute

  • dir

CLI 収集を適切に動作させるためには、デバイスにバナー設定を含めないでください。これをオフにする方法については、デバイスのマニュアルを参照してください。

CLI 収集ジョブは、Cisco Crosswork の UI からか、または API を使用して作成できます。UI からジョブを作成する方法については、 Cisco Crosswork UI からの収集ジョブの作成を参照してください。API からジョブを作成する方法については、 Cisco DevNet を参照してください。

CLI 収集 API のサンプルペイロード

Kafka 外部接続先の CLI 収集ジョブのペイロードの例を次に示します。この例では、特に 2 つの値に注意してください。

  1. デバイスは、IP アドレスではなく UUID で識別されます。

  2. 宛先も UUID によって参照されます。UI を使用して作成された収集ジョブの場合、Cisco Crosswork は UUID を検索します。独自の収集ジョブを作成するときは、これらの値を調べる必要があります。 

{
  "collection_job": {
    "application_context": {
      "context_id": "collection-job1",
      "application_id": "APP1"
    },
    "collection_mode": {
      "lifetime_type": "APPLICATION_MANAGED",
      "collector_type": "CLI_COLLECTOR"
    },
    "job_device_set": {
      "device_set": {
        "devices": {
          "device_ids": [
            "658adb03-cc61-448d-972f-4fcec32cbfe8"
          ]
        }
      }
    },
    "sensor_input_configs": [
      {
        "sensor_data": {
          "cli_sensor": {
            "command": "show platform"
          }
        },
        "cadence_in_millisec": "60000"
      }
    ],
    "sensor_output_configs": [
     {
        "sensor_data": {
          "cli_sensor": {
            "command": "show platform"
          }
        },
        "destination": {
          "destination_id": "1e71f2fb-ea65-4242-8efa-e33cec71b369",
          "context_id": "topic1"
        }
      }
    ]
  }
}

SNMP 収集ジョブ

Crosswork Data Gateway では、デバイスでサポートされている OID に基づく SNMP ベースのデータ収集をサポートしています。

SNMP コレクターは、設定プロファイル（収集する MIB オブジェクトのリストと取得先のデバイスのリスト）を取得するためのポーリング要求を Crosswork ネットワークコントローラ に行います。事前にパッケージ化された MIB モジュールのリストまたは MIB モジュールのカスタムリストを検索して、対応する OID を決定します。


（注）  
Crosswork Data Gateway は、システムにすでに含まれている標準的な MIB について、サードパーティ製デバイスで SNMP ポーリングを有効にします。独自の MIB は、収集要求が独自の MIB から MIB テーブル名またはスカラー名を参照する場合にのみ必要です。ただし、要求が OID ベースの場合、MIB は必要ありません。

OID が解決されると、SNMP コレクターへの入力として提供されます。SNMP OID ベースの収集ジョブは、Cisco Crosswork UI から、または API を使用して作成でき、SNMP トラップは API を使用して作成できます。

セクションカスタムパッケージの追加の説明に従って、Crosswork Data Gateway インスタンスにデバイスパッケージをインポートできます。

データポーリングとトラップでサポートされている SNMP バージョンは次のとおりです。

  • ポーリングデータ

    • SNMPv2

    • SNMPv3（no auth nopriv、auth no priv、authpriv）

    • サポートされている認証プロトコル：SHA-1、MD5

    • サポートされている priv プロトコル：AES-128、AES-192、AES-256、CiscoAES192、CiscoAES256、DES、および 3-DES。

  • トラップ

    • SNMPv2

    • SNMPv3（no auth nopriv、auth no priv、authpriv）

デバイスでの設定例：

次の表に、さまざまな SNMP 機能を有効にするサンプルコマンドを示します。詳細については、プラットフォーム固有のドキュメントを参照してください。

表 3. デバイスで SNMP を有効にする設定例

バージョン

コマンド

目的

V2c

snmp-server group <group_name> v2c

snmp-server user <user_name> <group_name> v2c

SNMP バージョン、ユーザー/ユーザーグループの詳細を定義します。

snmp-server host <host_ip> traps SNMP version <community_string> udp-port 1062

snmp-server host a.b.c.d traps version 2c v2test udp-port 1062

トラップデータの転送先を定義します。

（注）  

 

ここに記載されている IP アドレスは、Crosswork Data Gateway の仮想 IP アドレスである必要があります。

snmp-server traps snmp linkup

snmp-server traps snmp linkdown

リンクステータスを通知するトラップを有効にします。

V3

（注）  

 

SNMPv3 ユーザーのパスワードは、8 バイト以上にする必要があります。

snmp-server host <host_IP> traps version 3 priv <user_name> udp-port 1062

トラップデータの転送先を定義します。

（注）  

 

ここに記載されている IP アドレスは、Crosswork Data Gateway の仮想 IP アドレスである必要があります。

snmp-server user <user_name> <group_name> v3 auth md5 <password> priv aes 128 <password>

指定した名前付きアクセス リストのメンバに対して認証をイネーブルにするように SNMP サーバ グループを設定します。

snmp-server view <user_name> < MIB > included

何を報告する必要があるかを定義します。

snmp-server group <group_name> v3 auth notify <user_name> read <user_name> write <user_name>

SNMP バージョン、ユーザー/ユーザーグループの詳細を定義します。

snmp-serverenabletrapssnmp [authentication] [linkup] [linkdown] [warmstart] [coldstart]

  • オプションのキーワードを一切指定せずに使用した場合、authenticationFailure、linkUp、linkDown、warmStart、および coldStart の各トラップをイネーブルにします。

  • キーワード指定で使用した場合は、指定したタイプのトラップのみがイネーブルになります。たとえば、すべてのインターフェイスに対して linkUp と linkDown の SNMP トラップだけをグローバルにイネーブルにするには、このコマンドの snmp-serverenablesnmplinkuplinkdown という形式を使用します。

SNMP コレクターは、次の操作をサポートしています。

  • スカラー


    （注）  

    1 つの収集で複数のスカラー OID を要求する場合は、デバイスへの 1 つの getbulkrequestquery で複数の SNMP GET 要求をパックできます。

  • TABLE

  • WALK

  • COLUMN

これらの操作は、センサー設定で定義されます（以下のペイロード例を参照）。


（注）  

デバイスの応答時間が 1,500 ミ リ秒を超える場合は、オプションの deviceParams 属性 snmpRequestTimeoutMillis （ペイロード例には表示されていない）を使用する必要があります。デバイスの応答時間が長いことが確実でない限り、snmpRequestTimeoutMillis を使用することは推奨されません。

snmpRequestTimeoutMillis の値はミリ秒単位で指定する必要があります。

デフォルトの最小値は 1,500 ミリ秒です。ただし、この属性の最大値に制限はありません。

次に、SNMP 収集ジョブの例を示します。

{
  "collection_job": {
    "application_context": {
      "context_id": "collection-job1",
      "application_id": "APP1"
    },
    "collection_mode": {
      "lifetime_type": "APPLICATION_MANAGED",
      "collector_type": "SNMP_COLLECTOR"
    },
    "job_device_set": {
      "device_set": {
        "devices": {
          "device_ids": [
            "c70fc034-0cbd-443f-ad3d-a30d4319f937",
            "8627c130-9127-4ed7-ace5-93d3b4321d5e",
            "c0067069-c8f6-4183-9e67-1f2e9bf56f58"
          ]
        }
      }
    },
    "sensor_input_configs": [
      {
        "sensor_data": {
          "snmp_sensor": {
            "snmp_mib": {
              "oid": "1.3.6.1.2.1.1.3.0",
              "snmp_operation": "SCALAR"
            }
          }
        },
        "cadence_in_millisec": "60000"
      },
      {
        "sensor_data": {
          "snmp_sensor": {
            "snmp_mib": {
              "oid": "1.3.6.1.2.1.31.1.1",
              "snmp_operation": "TABLE"
            }
          }
        },
        "cadence_in_millisec": "60000"
      }
    ],
    "sensor_output_configs": [
      {
        "sensor_data": {
          "snmp_sensor": {
            "snmp_mib": {
              "oid": "1.3.6.1.2.1.1.3.0",
              "snmp_operation": "SCALAR"
            }
          }
        },
        "destination": {
          "destination_id": "4c2ab662-2670-4b3c-b7d3-b94acba98c56",
          "context_id": "topic1_461cb8aa-a16a-44b8-b79f-c3daf3ea925f"
        }
      },
      {
        "sensor_data": {
          "snmp_sensor": {
            "snmp_mib": {
              "oid": "1.3.6.1.2.1.31.1.1",
              "snmp_operation": "TABLE"
            }
          }
        },
        "destination": {
          "destination_id": "4c2ab662-2670-4b3c-b7d3-b94acba98c56",
          "context_id": "topic2_e7ed6300-fc8c-47ee-8445-70e543057f8a"
        }
      }
    ]
  }
}
SNMP トラップ収集ジョブ

SNMP トラップ収集ジョブは、API を介してのみ作成できます。トラップリスナーはポートでリッスンし、（関心のあるトピックに基づいて）受信者にデータをディスパッチします。


重要

SNMP トラップ収集を開始する前に、Common EMS Services アプリケーションをインストールし、SNMP のホスト情報を構成します。

Crosswork Data Gateway は、UDP ポート 1062 でトラップをリッスンします。


（注）  

SNMP トラップ収集ジョブを送信する前に、SNMP トラップをデバイス上で正しく設定して、Crosswork Data Gateway の仮想 IP アドレスに送信する必要があります。

SNMP トラップ収集ジョブのワークフロー

SNMP トラップを受信すると、Crosswork Data Gateway は以下を実行します。

  1. デバイスに対して収集ジョブが作成されているかどうかを確認します。

  2. トラップバージョンとコミュニティ文字列を確認します。


    （注）  

    Crosswork Data Gateway が SNMP トラップのコミュニティ文字列をチェックしないようにするには、Crosswork UI を介してデバイスを追加するときに、[SNMPトラップ無効化チェック（SNMP Disable Trap Check）] チェックボックスをオンにします。このオプションの詳細については、ユーザーインターフェイスを使用したデバイスの追加を参照してください。

  3. SNMP v3 の場合は、ユーザー認証と priv プロトコルとクレデンシャルも検証します。


    （注）  
    SNMPV3 auth-priv トラップは、デバイスまたはルータの engineId に依存して、ローカル USM ユーザーテーブルを維持します。したがって、デバイスまたはルータの engineId が変更されるたびに、トラップの受信が中断されます。トラップの受信を再開するには、それぞれのデバイスを取り外して取り付けてください。

Crosswork Data Gateway は、センサーパスに示されたトラップ OID に基づいてトラップをフィルタ処理し、要求されたトラップのみを送信します。

収集ジョブが無効か、デバイスに設定がないか、またはトラップが受信されない場合、ジョブのステータスは [不明（Unknown）] のままです。サポートされているトラップと MIB のリストについては、「SNMP での収集用に事前にロードしたトラップと MIB のリスト」を参照してください。

Crosswork Data Gateway は、次の 3 つのタイプの非 YANG/OID ベースのトラップをサポートします。

表 4. サポートされている非 YANG/OID ベースのトラップのリスト
センサーパス 目的
* フィルタなしでデバイスからプッシュされたすべてのトラップを取得します。
MIB レベルトラップ

1 つの MIB 通知の OID

（例：すべての isis-mib レベルトラップを取得する場合は 1.3.6.1.2.1.138.0）
特定のトラップ

特定のトラップの OID

（例：linkUp トラップを取得する場合は 1.3.6.1.6.3.1.1.5.4）

次に、SNMP トラップ収集ジョブの例を示します。

{
  "collection_job": {
    "application_context": {
      "context_id": "collection-job1",
      "application_id": "APP1"
    },
    "collection_mode": {
      "lifetime_type": "APPLICATION_MANAGED",
      "collector_type": "TRAP_COLLECTOR"
    },
    "job_device_set": {
      "device_set": {
        "devices": {
          "device_ids": [
            "a9b8f43d-130b-4866-a26a-4d0f9e07562a",
            "8c4431a0-f21d-452d-95a8-84323a19e0d6",
            "eaab2647-2351-40ae-bf94-6e4a3d79af3a"
          ]
        }
      }
    },
    "sensor_input_configs": [
      {
        "sensor_data": {
          "trap_sensor": {
            "path": "1.3.6.1.6.3.1.1.4"
          }
        },
        "cadence_in_millisec": "60000"
      }
    ],
    "sensor_output_configs": [
      {
        "sensor_data": {
          "trap_sensor": {
            "path": "1.3.6.1.6.3.1.1.4"
          }
        },
        "destination": {
          "destination_id": "4c2ab662-2670-4b3c-b7d3-b94acba98c56",
          "context_id": "topic1_696600ae-80ee-4a02-96cb-3a01a2415324"
        }
      }
    ]
  }
}
外部アプリケーションへのトラップ転送の有効化

デバイス上の Crosswork に必要なトラップのみを選択して有効にすることをお勧めします。

接続先で受信したデータのトラップタイプを識別するには、oid （OBJECT_IDENTIFIER。1.3.6.1.6.3.1.1.4.1.0 など）と OidRecords の oid に関連付けられている strValue を検索します（アプリケーションは対象の OID を照合してトラップの種類を特定できます）。

次に、トラップを外部アプリケーションに転送するための値とペイロードの例を示します。

  • リンク アップ

    1.3.6.1.6.3.1.1.4.1.0 = 1.3.6.1.6.3.1.1.5.4

  • Link Down

    1.3.6.1.6.3.1.1.4.1.0 = 1.3.6.1.6.3.1.1.5.3

  • Syslog

    1.3.6.1.6.3.1.1.4.1.0 = 1.3.6.1.4.1.9.9.41.2.0.1

  • Cold Start

    1.3.6.1.6.3.1.1.4.1.0 = 1.3.6.1.6.3.1.1.5.1

{
  "nodeIdStr": "BF5-XRV9K1.tr3.es",
  "nodeIdUuid": "C9tZ5lJoSJKf5OZ67+U5JQ==",
  "collectionId": "133",
  "collectionStartTime": "1580931985267",
  "msgTimestamp": "1580931985267",
  "dataGpbkv": [
    {
      "timestamp": "1580931985267",
      "name": "trapsensor.path",
      "snmpTrap": {
        "version": "V2c",
        "pduType": "TRAP",
        "v2v3Data": {
          "agentAddress": "172.70.39.227",
          "oidRecords": [
            {
              "oid": "1.3.6.1.2.1.1.3.0",
              "strValue": "7 days, 2:15:17.02"
            },
            {
              "oid": "1.3.6.1.6.3.1.1.4.1.0",  // This oid is the Object Identifier.
              "strValue": "1.3.6.1.6.3.1.1.5.3" // This is the value that determines the kind of trap.
            },
            {
              "oid": "1.3.6.1.2.1.2.2.1.1.8",
              "strValue": "8"
            },
            {
              "oid": "1.3.6.1.2.1.2.2.1.2.8",
              "strValue": "GigabitEthernet0/0/0/2"
            },
            {
              "oid": "1.3.6.1.2.1.2.2.1.3.8",
              "strValue": "6"
            },
            {
              "oid": "1.3.6.1.4.1.9.9.276.1.1.2.1.3.8",
              "strValue": "down"
            }
          ]
        }
      }
    }
  ],
  "collectionEndTime": "1580931985267",
  "collectorUuid": "YmNjZjEzMTktZjFlOS00NTE5LWI4OTgtY2Y1ZmQxZDFjNWExOlRSQVBfQ09MTEVDVE9S",
  "status": {
    "status": "SUCCESS"
  },
  "modelData": {},
  "sensorData": {
    "trapSensor": {
      "path": "1.3.6.1.6.3.1.1.5.4"
    }
  },
  "applicationContexts": [
    {
      "applicationId": "APP1",
      "contextId": "collection-job-snmp-traps"
    }
  ]
}

MDT 収集ジョブ

Crosswork Data Gateway は、モデル駆動型テレメトリ（MDT）を使用してネットワークデバイスからのデータ収集をサポートし、デバイスからのテレメトリストリームを直接消費します（IOS-XR ベースのプラットフォームのみ）。

Crosswork Data Gateway は、次のトランスポートモードのデータ収集をサポートしています。

  • MDT TCP ダイヤルアウトモード

Cisco Crosswork は NSO を利用して必要な MDT 設定をデバイスにプッシュし、対応する収集ジョブの設定を Crosswork Data Gateway に送信します。


（注）  

  • バックアップ操作と復元操作の間に既存の MDT ジョブに何らかの変更（更新）がある場合、Crosswork ネットワークコントローラ はデバイス上で設定更新のジョブを再生しません。これには NSO が関係するためです。NSO/デバイスの設定を復元する必要があります。Crosswork ネットワークコントローラ はデータベース内のジョブのみを復元します。

  • YANG モジュールを使用する前に、サポートされているかどうかを確認します。「MDT での収集用に事前にロードした YANG モジュールのリスト」の項を参照してください。

次に、MDT 収集のペイロードの例を示します。

{
	"collection_job": {
		"job_device_set": {
			"device_set": {
				"device_group": "mdt"
			}
		},
		"sensor_output_configs": [{
				"sensor_data": {
					"mdt_sensor": {
						"path": "Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters"
					}
				},
				"destination": {
					"context_id": "cw.mdt_sensor.cisco-ios-xr-infra-statsd-oper.gpb",
					"destination_id": "c2a8fba8-8363-3d22-b0c2-a9e449693fae"
				}
			},
			{
				"sensor_data": {
					"mdt_sensor": {
						"path": "Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/data-rate"
					}
				},
				"destination": {
					"context_id": "cw.mdt_sensor.cisco-ios-xr-infra-statsd-oper.gpb",
					"destination_id": "c2a8fba8-8363-3d22-b0c2-a9e449693fae"
				}
			}
		],
		"sensor_input_configs": [{
				"sensor_data": {
					"mdt_sensor": {
						"path": "Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/data-rate"
					}
				},
				"cadence_in_millisec": "70000"
			}, {
				"sensor_data": {
					"mdt_sensor": {
						"path": "Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters"
					}
				},
				"cadence_in_millisec": "70000"
			}
		],
		"application_context": {
			"context_id": "c4",
			"application_id": "a4-mdt"
		},
		"collection_mode": {
			"lifetime_type": "APPLICATION_MANAGED",
			"collector_type": "MDT_COLLECTOR"
		}
	}
}

MDT 収集ジョブのワークフロー

MDT ベースの KPI がデバイスでアクティブ化されると、Cisco Crosswork

  1. 構成要求を NSO に送信して、ターゲットデバイスでのデータ収集を有効にします。

  2. Crosswork Data Gateway に収集ジョブ作成要求を送信します。

  3. Crosswork Data Gateway は、収集したデータを指定した宛先に送信するためのディストリビューションを作成します。

Syslog 収集ジョブ

Crosswork Data Gateway は、デバイスからの syslog ベースのイベント収集をサポートしています。


重要

syslog トラップ収集を開始する前に、Common EMS Services アプリケーションをインストールし、syslog のホスト情報を構成します。

サポートされている syslog 形式は、次のとおりです。

  • RFC5424 syslog 形式

  • RFC3164 syslog 形式


（注）  

ネットワーク内の Crosswork Data Gateway から syslog データを収集するには、デバイスを追加するときに YANG_CLI 機能を選択し、Crosswork Data Gateway から syslog データを受信するように他のパラメータを設定します。プラットフォーム固有のマニュアルを参照してください。

構成手順の順序は重要ではありませんが、両方の手順を完了する必要があります。そうしないと、データが送信されません。デバイスの設定例については、「デバイスでの非セキュア Syslog の設定」を参照してください。Cisco Crosswork では、デバイスへのセキュアな Syslog 通信を設定することもできます。詳細については、デバイスでのセキュア Syslog の設定を参照してください。

syslog 収集ペイロードの例
{
  "collection_job": {
      "job_device_set": {
      "device_set": {
        "devices": {
          "device_ids": [
            "c6f25a33-92e6-468a-ba0d-15490f1ce787"
          ]
        }
      }
    },
    "sensor_output_configs": [
      {
        "sensor_data": {
          "syslog_sensor": {
            "pris": {
                "facilities": [0, 1, 3, 23,4],
                "severities": [0, 4, 5, 6, 7]
            }
        }
        },
        "destination": {
          "context_id": "syslogtopic",
          "destination_id": "c2a8fba8-8363-3d22-b0c2-a9e449693fae"
        }
      }
    ],
    "sensor_input_configs": [
      {
        "sensor_data": {
          "syslog_sensor": {
            "pris": {
                "facilities": [0,1, 3, 23,4],
                "severities": [0,4, 5, 6, 7]
            }
        }
        },
        "cadence_in_millisec": "60000"
      }
    ],
    "application_context": {
      "context_id": "demomilesstone2syslog",
      "application_id": "SyslogDemo2"
    },
    "collection_mode": {
      "lifetime_type": "APPLICATION_MANAGED",
      "collector_type": "SYSLOG_COLLECTOR"
    }
  }
}

  • Syslog データ収集の出力は、PRI ベースの SyslogSensor またはフィルタベースの SyslogSensor を指定することでフィルタ処理することができます。ペイロードに記載されているファシリティと重大度に一致する syslog イベントが、指定された宛先に送信されます。一致しない他のすべての Syslog イベントはドロップされます。正規表現、重大度、または機能に基づいてフィルタを指定できます。

  • 重大度と機能の値を指定した場合、両方の条件は、フィルタレベルで指定された論理演算子に基づいて結合されます。

  • 論理演算子 AND または OR を使用して、最大 3 つのフィルタの組み合わせを指定できます。デフォルトでは、演算子を指定しない場合、AND 演算子が適用されます。

Syslog 収集ジョブの出力

Crosswork Network Controller の UI からデバイスをオンボーディングする場合（[デバイス管理（Device Management）] > [ネットワークデバイス（Network Devices）] > [デバイスの詳細（Device Details）]）、[Syslog形式（Syslog Format）] フィールドで選択した値によって、デバイスから受信した syslog イベントを Syslog コレクターで解析する形式が設定されます。[不明（UNKNOWN）]、[RFC5424]、または [RFC3164] のいずれかを選択できます。

次に、各オプションの出力例を示します。

  1. [不明（UNKNOWN）]：Syslog 収集ジョブの出力に、デバイスから受信した syslog イベントが含まれています。


    （注）  

    デバイスは RFC5424/RFC3164 形式で syslog イベントを生成するように設定されていても [Syslog形式（Syslog Format）] フィールドに形式が指定されていない場合、デフォルトでは [不明（UNKNOWN）] と見なされます。

    サンプル出力：
    node_id_str: "xrv9k-VM8"
node_id_uuid: ":i\300\216>\366BM\262\270@\337\225\2723&"
collection_id: 1056
collection_start_time: 1616711596200
msg_timestamp: 1616711596201
data_gpbkv {
  timestamp: 1616711596201
  name: "syslogsensor.path"
  fields {
    name: "RAW"
    string_value: "<6>1 Mar 25 15:34:41.321 PDT - SSHD_ 69570 - - 98949: RP/0/RP0/CPU0:SSHD_[69570]: %SECURITY-SSHD-6-INFO_SUCCESS : Successfully authenticated user \'admin\' from \'40.40.40.116\' on \'vty0\'(cipher \'aes128-ctr\', mac \'hmac-sha1\') \n"
  }
  fields {
    name: "DEVICE_IP"
    string_value: "40.40.40.30"
  }
}
collection_end_time: 1616711596200
collector_uuid: "17328736-b726-4fe3-b922-231a4a30a54f:SYSLOG_COLLECTOR"
status {
  status: SUCCESS
}
model_data {
}
sensor_data {
  syslog_sensor {
    pris {
      facilities: 0
      facilities: 3
      facilities: 4
      facilities: 23
      severities: 0
      severities: 5
      severities: 6
      severities: 7
    }
  }
}
application_contexts {
  application_id: "SyslogApp-xr-8-job1"
  context_id: "xr-8-job1"
}
version: "1"

  2. [RFC5424]：デバイスが syslog イベントを RFC5424 形式で生成するように設定され、[Syslog 形式（Syslog Format）] フィールドで [RFC5424] 形式が選択されている場合、Syslog 収集ジョブ収集の出力には、デバイスから受信した syslog イベント（RAW）とデバイスからの RFC5424 のベストエフォート解析済みの syslog イベントが含まれます。


    （注）  

    Syslog コレクターは、次の Java RegEx パターンに従ってベストエフォートで syslog イベントを解析します。

    サンプル出力：

    ....
....
 
 
collection_start_time: 1596307542398
msg_timestamp: 1596307542405
data_gpbkv {
  timestamp: 1596307542405
  name: "syslogsensor.path"
  fields {
    name: "RAW"
    string_value: "<13>1 2020 Aug  1 12:03:32.461 UTC:  iosxr254node config 65910 - - 2782: RP/0/RSP0/CPU0:2020 Aug  1 12:03:32.461 UTC: config[65910]: %MGBL-SYS-5-CONFIG_I : Configured from console by admin on vty0 (10.24.88.215) \n"
  }
  fields {
    name: "RFC5424"
    string_value: "pri=13,  severity=5,  facility=1,  version=1,  date=2020-08-01T12:03:32.461,  remoteAddress=/172.28.122.254,  host=\'iosxr254node\',  message=\'2782: RP/0/RSP0/CPU0:2020 Aug  1 12:03:32.461 UTC: config[65910]: %MGBL-SYS-5-CONFIG_I : Configured from console by admin on vty0 (10.24.88.215) \', messageId=null, processName=config, structuredDataList=null"
  }
  fields {
    name: "DEVICE_IP"
    string_value: "172.28.122.254"
  }
}
collection_end_time: 1596307542404
collector_uuid: "ac961b09-8f67-4c93-a99a-31eef50f7fa9:SYSLOG_COLLECTOR"
status {
  status: SUCCESS
}
...
...

  3. [RFC3164]：デバイスが syslog イベントを RFC3164 形式で生成するように設定され、[Syslog 形式（Syslog Format）] フィールドで [RFC3164] 形式が選択されている場合、Syslog ジョブ収集の出力には、RAW（デバイスから受信したもの）syslog イベントとデバイスかの RFC3164 のベストエフォート解析済みの syslog イベントの両方が含まれます。


    （注）  

    Syslog コレクターは、次の Java RegEx パターンに従ってベストエフォートで syslog イベントを解析します。
    サンプル出力：
    ....
.....
collection_id: 20
collection_start_time: 1596306752737
msg_timestamp: 1596306752743
data_gpbkv {
  timestamp: 1596306752743
  name: "syslogsensor.path"
  fields {
    name: "RAW"
    string_value: "<14>2020 Aug  1 11:50:22.799 UTC:  iosxr254node 2756: RP/0/RSP0/CPU0:2020 Aug  1 11:50:22.799 UTC: config[65910]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user \'admin\'. Use \'show configuration commit changes 1000000580\' to view the changes. \n"
  }
  fields {
    name: "RFC3164"
    string_value: "pri=14,  severity=6,  facility=1,  version=null,  date=2020-08-01T11:50:22.799,  remoteAddress=/172.28.122.254,  host=\'iosxr254node\',  message=\'RP/0/RSP0/CPU0:2020 Aug  1 11:50:22.799 UTC: config[65910]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user \'admin\'. Use \'show configuration commit changes 1000000580\' to view the changes. \', tag=2756"
  }
  fields {
    name: "DEVICE_IP"
    string_value: "172.28.122.254"
  }
}
collection_end_time: 1596306752742
collector_uuid: "ac961b09-8f67-4c93-a99a-31eef50f7fa9:SYSLOG_COLLECTOR"
status {
  status: SUCCESS
}
....
....

Syslog コレクターが [Syslog形式（Syslog Format）] フィールドで指定された形式に従って syslog イベントを解析できない場合、Syslog 収集ジョブの出力には、デバイスから受信した syslog イベント（RAW）が含まれます。

デバイスでの非セキュア Syslog の設定

この項では、デバイスでの RFC3164 形式または RFC5424 形式での syslog の設定例を示します。

デュアルスタックの Crosswork 展開では、syslog イベントが中断することなくログに記録されるように、デバイスはデバイスインベントリで設定されているのと同じ IP スタック（IPv4 または IPv6）を使用してイベントを送信する必要があります。データゲートウェイのホストアドレスを FQDN ではなく IP アドレス（IPv4 または IPv6）として設定することを推奨します。これにより、データゲートウェイに送信されるイベント内のデバイスの送信元 IP が、デバイスインベントリ内のデバイスの設定と一致します。


（注）  

デバイスに設定する syslog 形式は、Crosswork UI を使用してデバイスを追加したときに指定した形式と一致する必要があります。詳細については、ユーザーインターフェイスを使用したデバイスの追加を参照してください。

RFC3164 Syslog 形式の設定


（注）  
次のコードで強調表示されている設定は、解析された出力でのフォーマットの問題を回避するために必要です。

IOS XR の場合： 

logging <CDG IP> port 9514 OR logging <CDG IP> vrf <vrfname> port 9514 
logging trap [severity]
logging facility [facility value]
logging suppress duplicates
service timestamps log datetime msec show-timezone year
logging hostnameprefix <some host related prefix e.g.iosxrhost2>

IOS XE の場合： 

no logging message-counter syslog 
logging trap <serverity>
logging facility <facility>
logging host <CDG IP> transport tcp port 9898 session-id string <sessionidstring> --> To use TCP channel
OR
logging host <CDG IP> transport udp port 9514 session-id string <sessionidstring> ---> To use UDP channel
OR
logging host <CDG IP> vrf Mgmt-intf transport udp port 9514 session-id string <sessionidstring> --> To use UDP via vrf 
service timestamps log datetime msec year show-timezone

RFC5424 Syslog 形式の設定

IOS XR の場合： 

logging <CDG IP> port 9514 OR logging <server 1> vrf <vrfname> port 9514 
logging trap [severity]
logging facility [facility value]
logging suppress duplicates
service timestamps log datetime msec show-timezone year
logging hostnameprefix <some host related prefix e.g.iosxrhost2>
logging format rfc5424

IOS XE の場合： 

no logging message-counter syslog
logging trap <serverity>
logging facility <facility>
logging host <CDG IP> transport tcp port 9898 session-id string <sessionidstring> --> To use TCP channel
OR
logging host <CDG IP> transport udp port 9514 session-id string <sessionidstring> ---> To use UDP channel
OR
logging host <CDG IP> vrf Mgmt-intf transport udp port 9514 session-id string <sessionidstring> --> To use UDP via vrf 
service timestamps log datetime msec year show-timezone
logging trap syslog-format 5424 --> if applicable
デバイスでのセキュア Syslog の設定

デュアルスタックの Crosswork 展開では、syslog イベントが中断することなくログに記録されるように、デバイスはデバイスインベントリで設定されているのと同じ IP スタック（IPv4 または IPv6）を使用してイベントを送信する必要があります。データゲートウェイのホストアドレスがデバイスで FQDN に設定され、IPv4 と IPv6 の両方に解決される場合は、データゲートウェイに送信されるイベント内のデバイスの送信元 IP が、デバイスインベントリ内のデバイスの設定と一致することを確認してください。

デバイスとの保護された syslog 通信を確立するには、次の手順を使用します。

  1. Cisco Crosswork の [証明書管理 UI（Certificate Management）] ページから Cisco Crosswork 信頼チェーンをダウンロードします。

    1. Cisco Crosswork の UIで、[管理（Administration）] > [証明書管理（Certificate Management）] に移動します。

    2. 「crosswork-device-syslog」行で [i] をクリックします。

    3. [すべてエクスポート（Export All）] をクリックして、証明書をダウンロードします。

      次のファイルがシステムにダウンロードされます。

  2. デバイスに Cisco Crosswork 信頼チェーンを設定します。

    デバイスで Cisco Crosswork トラストポイントを有効にするには、設定例を参照してください。

    TLS を有効にする IOS XR デバイスの設定例 
    RP/0/RSP0/CPU0:ASR9k(config)#crypto ca trustpoint syslog-root
RP/0/RSP0/CPU0:ASR9k(config-trustp)#enrollment terminal
RP/0/RSP0/CPU0:ASR9k(config-trustp)#crl optional
RP/0/RSP0/CPU0:ASR9k(config-trustp)#commit
RP/0/RSP0/CPU0:ASR9k(config-trustp)#end
RP/0/RSP0/CPU0:ASR9k#
RP/0/RSP0/CPU0:ASR9k#crypto ca authenticate syslog-root
Fri Jan 22 11:07:41.880 GMT
  
  
Enter the base 64 encoded certificate.
End with a blank line or the word "quit" on a line by itself
  
-----BEGIN CERTIFICATE-----
MIIGKzCCBBOgAwIBAgIRAKfyU89yjmrXVDRKBWuSGPgwDQYJKoZIhvcNAQELBQAw
bDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMREwDwYDVQQHEwhTYW4gSm9zZTEa
................................................................
................................................................
jPQ/UrO8N3sC1gGJX7CIIh5cE+KIJ51ep8i1eKSJ5wHWRTmv342MnG2StgOTtaFF
vrkWHD02o6jRuYXDWEUptDOg8oEritZb+SNPXWUc/2mbYog6ks6EeMC69VjkZPo=
-----END CERTIFICATE-----
  
Read 1583 bytes as CA certificate
  Serial Number  : A7:F2:53:CF:72:8E:6A:D7:54:34:4A:05:6B:92:18:F8
  Subject:
                CN=Crosswork Device Root CA,O=CISCO SYSTEMS INC,L=San Jose,ST=CA,C=US
  Issued By      :
                CN=Crosswork Device Root CA,O=CISCO SYSTEMS INC,L=San Jose,ST=CA,C=US
  Validity Start : 02:37:09 UTC Sat Jan 16 2021
  Validity End   : 02:37:09 UTC Thu Jan 15 2026
  SHA1 Fingerprint:
                209B3815271C22ADF78CB906F6A32DD9D97BBDBA
  
Fingerprint: 2FF85849EBAAB9B059ACB9F5363D5C9CDo you accept this certificate? [yes/no]: yes
RP/0/RSP0/CPU0:ASR9k#config
RP/0/RSP0/CPU0:ASR9k(config)#crypto ca trustpoint syslog-inter
RP/0/RSP0/CPU0:ASR9k(config-trustp)#enrollment terminal
RP/0/RSP0/CPU0:ASR9k(config-trustp)#crl optional
RP/0/RSP0/CPU0:ASR9k(config-trustp)#commit
RP/0/RSP0/CPU0:ASR9k#crypto ca authenticate syslog-inter
Fri Jan 22 11:10:30.090 GMT
  
  
Enter the base 64 encoded certificate.
End with a blank line or the word "quit" on a line by itself
  
-----BEGIN CERTIFICATE-----
MIIGFDCCA/ygAwIBAgIRAkhqHQXcJzQzeQK6U2wn8PIwDQYJKoZIhvcNAQELBQAw
bDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMREwDwYDVQQHEwhTYW4gSm9zZTEa
................................................................
................................................................
5lBk617z6cxFER5c+/PmJFhcreisTxXg1aJbFdnB5C8f+0uUIdLghykQ/zaZGuBn
AAB70c9r9OeKGJWzvv1e2U8HH1pdQ/nd
-----END CERTIFICATE-----
  
Read 1560 bytes as CA certificate
  Serial Number  : 02:48:6A:1D:05:DC:27:34:33:79:02:BA:53:6C:27:F0:F2
  Subject:
                CN=device-syslog,O=CISCO SYSTEMS INC,L=San Jose,ST=CA,C=US
  Issued By      :
                CN=Crosswork Device Root CA,O=CISCO SYSTEMS INC,L=San Jose,ST=CA,C=US
  Validity Start : 02:37:11 UTC Sat Jan 16 2021
  Validity End   : 02:37:11 UTC Mon Jan 16 2023
  SHA1 Fingerprint:
                B06F2BFDE95413A8D08A01EE3511BC3D42F01E59
  
CA Certificate validated using issuer certificate.
RP/0/RSP0/CPU0:ASR9k#show crypto ca certificates
Fri Jan 22 15:45:17.196 GMT
 
 
Trustpoint       : syslog-root
==================================================
CA certificate
  Serial Number  : A7:F2:53:CF:72:8E:6A:D7:54:34:4A:05:6B:92:18:F8
  Subject:
        CN=Crosswork Device Root CA,O=CISCO SYSTEMS INC,L=San Jose,ST=CA,C=US
  Issued By      :
        CN=Crosswork Device Root CA,O=CISCO SYSTEMS INC,L=San Jose,ST=CA,C=US
  Validity Start : 02:37:09 UTC Sat Jan 16 2021
  Validity End   : 02:37:09 UTC Thu Jan 15 2026
  SHA1 Fingerprint:
         209B3815271C22ADF78CB906F6A32DD9D97BBDBA
 
 
Trustpoint       : syslog-inter
==================================================
CA certificate
  Serial Number  : 02:48:6A:1D:05:DC:27:34:33:79:02:BA:53:6C:27:F0:F2
  Subject:
        CN=device-syslog,O=CISCO SYSTEMS INC,L=San Jose,ST=CA,C=US
  Issued By      :
        CN=Crosswork Device Root CA,O=CISCO SYSTEMS INC,L=San Jose,ST=CA,C=US
  Validity Start : 02:37:11 UTC Sat Jan 16 2021
  Validity End   : 02:37:11 UTC Mon Jan 16 2023
  SHA1 Fingerprint:
         B06F2BFDE95413A8D08A01EE3511BC3D42F01E59
RP/0/RSP0/CPU0:ASR9k(config)#logging tls-server syslog-tb131
RP/0/RSP0/CPU0:ASR9k(config-logging-tls-peer)#tls-hostname 10.13.0.159
RP/0/RSP0/CPU0:ASR9k(config-logging-tls-peer)#trustpoint syslog-inter
RP/0/RSP0/CPU0:ASR9k(config-logging-tls-peer)#severity debugging
RP/0/RSP0/CPU0:ASR9k(config-logging-tls-peer)#vrf default
RP/0/RSP0/CPU0:ASR9k(config-logging-tls-peer)#commit
RP/0/RSP0/CPU0:ASR9k(config-logging-tls-peer)#exit
RP/0/RSP0/CPU0:ASR9k(config)#exit
RP/0/RSP0/CPU0:ASR9k#exit
RP/0/RSP0/CPU0:ASR9k#show running-config logging
Fri Jan 22 11:17:19.385 GMT
logging tls-server syslog-tb131
vrf default
severity debugging
trustpoint syslog-inter 
tls-hostname <CDG VIP FQDN name>
!
logging trap debugging
logging format rfc5424
logging facility user
logging hostnameprefix ASR9k
logging suppress duplicates
  
RP/0/RSP0/CPU0:ASR9k#

    TLS を有効にする IOS XE デバイスの設定例 

    csr8kv(config)#crypto pki trustpoint syslog-root
csr8kv(ca-trustpoint)#enrollment terminal
csr8kv(ca-trustpoint)#revocation-check none
csr8kv(ca-trustpoint)#chain-validation stop
csr8kv(ca-trustpoint)#end
csr8kv(config)#crypto pki authenticate syslog-root
 
Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself
 
-----BEGIN CERTIFICATE-----
MIIFPjCCAyYCCQCO6pK5AOGYdjANBgkqhkiG9w0BAQsFADBhMQswCQYDVQQGEwJV
UzELMAkGA1UECAwCQ0ExETAPBgNVBAcMCE1pbHBpdGFzMQ4wDAYDVQQKDAVDaXNj
................................................................
................................................................
JbimOpXAncoBLo14DXOJLvMVRjn1EULE9AXXCNfnrnBx7jL4CV+qHgEtF6oqclFW
JEA=
-----END CERTIFICATE-----
 
Certificate has the following attributes:
       Fingerprint MD5: D88D6D8F E53750D4 B36EB498 0A435DA1
      Fingerprint SHA1: 649DE822 1C222C1F 5101BEB8 B29CDF12 5CEE463B
 
% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
% Certificate successfully imported
 
 
csr8kv(config)#crypto pki trustpoint syslog-intermediate
csr8kv(ca-trustpoint)#enrollment terminal
csr8kv(ca-trustpoint)#revocation-check none
csr8kv(ca-trustpoint)#chain-validation continue syslog-root
csr8kv(ca-trustpoint)#end
csr8kv(config)#crypto pki authenticate syslog-intermediate
 
Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself
 
-----BEGIN CERTIFICATE-----
MIIFfTCCA2WgAwIBAgICEAAwDQYJKoZIhvcNAQELBQAwXDELMAkGA1UEBhMCVVMx
EzARBgNVBAgMCkNhbGlmb3JuaWExDjAMBgNVBAoMBUNpc2NvMQ4wDAYDVQQLDAVT
................................................................
................................................................
Nmz6NQynD7bxdQa9Xq9kyPuY3ZVKXkf312IRH0MEy2yFX/tAen9JqOeZ1g8canmw
TxsWA5TLzy1RmxqQh88f0CM=
-----END CERTIFICATE-----
Trustpoint 'syslog-intermediate' is a subordinate CA.
but certificate is not a CA certificate.
Manual verification required
Certificate has the following attributes:
       Fingerprint MD5: FE27BDBE 9265208A 681670AC F59A2BF1
      Fingerprint SHA1: 03F513BD 4BEB689F A4F4E001 57EC210E 88C7BD19
 
csr8kv(config)#logging host <CDG Southbound IP> transport tls port 6514
csr8kv(config)#logging trap informational syslog-format rfc5424
csr8kv(config)#logging facility user
csr8kv(config)#service timestamps log datetime msec year show-timezone

csr8kv(config)#logging tls-profile tlsv12

    FQDN をサポートするための Syslog 構成

    サンプルのデバイス構成に加えて次のコマンドを使用して、TLS が FQDN をサポートできるようにします。

    1. デバイスでドメイン名および DNS IP を設定します。

      IOS XR の場合： 

      RP/0/RSP0/CPU0:ASR9k#config
RP/0/RSP0/CPU0:ASR9k(config)#domain name <DNS domain name>
RP/0/RSP0/CPU0:ASR9k(config)#domain name-server <DNS server IP>

      IOS XE の場合： 

      Device(config)# ip name-server <IP of DNS>
Device(config)# ip domain name <domain name>

    2. tls-hostname の Crosswork Data Gateway VIP FQDN を設定します。

      IOS XR の場合： 

      RP/0/RSP0/CPU0:ASR9k(config)#logging tls-server syslog-tb131
RP/0/RSP0/CPU0:ASR9k(config-logging-tls-peer)#tls-hostname <CDG VIP FQDN>

      IOS XE の場合： 

      Device(config)# logging host fqdn ipv4 <hostname> transport tls port 6514

gNMI 収集ジョブ

Crosswork ネットワークコントローラ は、Crosswork Data Gateway を介した gRPC ネットワーク管理インターフェイス（gNMI）ベースのテレメトリデータの収集をサポートしています。サブスクリプションに基づく gNMI ダイヤルイン（gRPC ダイヤルイン）ストリーミングのテレメトリデータと、要求した接続先への後続のサブスクリプション応答（通知）のリレーのみをサポートします。


（注）  

モデルがターゲットのデバイスプラットフォームでサポートされている限り、gNMI 収集はサポートされます。 gNMI 収集ジョブを送信するには、デバイスで gNMI を設定しておく必要があります。プラットフォーム固有のマニュアルを確認します。

デバイスで gNMI を設定するには、「gNMI用のデバイス設定」を参照してください。

gNMI では、セキュアモードと非セキュアモードの両方をデバイスで共存させることができます。Crosswork ネットワークコントローラ は、インベントリで渡された情報に基づいて、非セキュアモードよりもセキュアモードを優先します。

デバイスがリロードされると、gNMI コレクターは既存のサブスクリプションがデバイスに再サブスクライブされるようにします。

gNMI 仕様には、メッセージの終わりをマークする方法がありません。したがって、接続先とディスパッチのパターンは gNMI コレクターではサポートされません。

Crosswork Data Gateway は、gNMI の次のタイプのサブスクライブオプションをサポートしています。

表 5. gNMI のサブスクリプションオプション

タイプ

サブタイプ

説明

1 回

指定したすべてのパスについて、システム設定の現在のスナップショットを 1 回だけ収集して送信します。

ストリーム

SAMPLE

パターンベースの収集。

ON_CHANGE

最初の応答には、サブスクライブしているパスのすべての要素の状態が含まれ、その後に、変更リーフ値に対する後続の更新が含まれています。

TARGET_DEFINED

ルータ/デバイスは、サブスクライブしているパス（つまり、SAMPLE または ON_CHANGE のいずれか）に基づいてリーフ単位でサブスクリプションのモードを選択します。

Crosswork Data Gateway は、デバイスへの単一のサブスクリプションリストで複数のサブスクリプションパスをサブスクライブする機能をサポートしています。たとえば、ON_CHANGE とサブスクリプションモードの ONCE 収集ジョブの組み合わせを指定できます。ON_CHANGE モードは、指定したパスの特定の要素の変更時にのみデータを収集します。一方、サブスクリプションモードの ONCE は、指定したパスの現在のシステムデータを 1 回だけ収集して送信します。


（注）  

  • Crosswork Data Gateway は、1 つ以上のモードのサポートの宣言をデバイスに依存します。

  • デフォルト値の gNMI センサーパスはペイロードに表示されません。これは既知の protobuf の動作です。

    boolean の場合、デフォルト値は false です。enum の場合は、gnmi.proto が指定されます。

    例 1：

    message GNMIDeviceSetting {
bool suppress_redundant = 1;
bool allow_aggregation = 4;
bool updates_only = 6;
}

    例 2：

    enum SubscriptionMode {
TARGET_DEFINED = 0; //default value will not be printed
ON_CHANGE = 1;
SAMPLE = 2;
}
次に、gNMI 収集ペイロードのサンプルを示します。このサンプルでは、デバイスグループ「milpitas」の 2 つの集まりが表示されます。最初は、60 秒ごとに「mode」=「SAMPLE」を使用してインターフェイス統計情報を収集します。2 番目のジョブは、インターフェイスの状態（アップ/ダウン）の変更をキャプチャします。これが検出されると、単に「mode = "STREAM"」がコレクターに送信されます。
{
    "collection_job": {
        "job_device_set": {
            "device_set": {
                "device_group": "milpitas"
            }
        },
        "sensor_output_configs": [{
            "sensor_data": {
                "gnmi_standard_sensor": {
                    "Subscribe_request": {
                        "subscribe": {
                            "subscription": [{
                                "path": {
                                    "origin": "openconfig-interfaces",
                                    "elem": [{
                                        "name": "interfaces/interface/state/ifindex"
                                    }]
                                },
                                "mode": "SAMPLE",
                                "sample_interval": 10000000000
                            }, {
                                "path": {
                                    "origin": "openconfig-interfaces",
                                    "elem": [{
                                        "name": "interfaces/interfaces/state/counters/out-octets"
                                    }]
                                },
                                "mode": "ON_CHANGE",
                                "sample_interval": 10000000000
                            }],
                            "mode": "STREAM",
                            "encoding": "JSON"
                        }
                    }
                }
            },
            "destination": {
                "context_id": "hukarz",
                "destination_id": "c2a8fba8-8363-3d22-b0c2-a9e449693fae"
            }
        }],
        "sensor_input_configs": [{
            "sensor_data": {
                "gnmi_standard_sensor": {
                    "Subscribe_request": {
                        "subscribe": {
                            "subscription": [{
                                "path": {
                                    "origin": "openconfig-interfaces",
                                    "elem": [{
                                        "name": "interfaces/interface/state/ifindex"
                                    }]
                                },
                                "mode": "SAMPLE",
                                "sample_interval": 10000000000
                            }, {
                                "path": {
                                    "origin": "openconfig-interfaces",
                                    "elem": [{
                                        "name": "interfaces/interfaces/state/counters/out-octets"
                                    }]
                                },
                                "mode": "ON_CHANGE",
                                "sample_interval": 10000000000
                            }],
                            "mode": "STREAM",
                            "encoding": "JSON"
                        }
                    }
                }
            },
            "cadence_in_millisec": "60000"
        }],
        "application_context": {
            "context_id": "testing.group.gnmi.subscription.onchange",
            "application_id": "testing.postman.gnmi.standard.persistent"
        },
        "collection_mode": {
            "lifetime_type": "APPLICATION_MANAGED",
            "collector_type": "GNMI_COLLECTOR"
        }
    }
}
デバイスと Crosswork Data Gateway 間でのセキュア gNMI 通信の有効化

Cisco Crosswork は 1 つのルート CA 証明書（自己署名または信頼できるルート CA による署名）のみを使用できます。つまり、すべてのデバイス証明書は同じ CA による署名であることが必要です。

信頼できる別のルート CA によって署名された証明書がある場合は、最初の手順をスキップして手順 2 から開始し、Cisco Crosswork に rootCA 証明書をインポートできます。

Cisco Crosswork とデバイス間でセキュア gNMI を有効にするには、次の手順を実行します。

  1. 証明書を生成します。「デバイス証明書の生成」を参照してください。

  2. Cisco Crosswork の [Crosswork 証明書管理（Crosswork Certificate Management）] の UI に証明書をアップロードします。「gNMI 証明書の設定」を参照してください。

  3. Cisco Crosswork の UI からセキュア gNMI ポートの詳細を使用してデバイス設定を更新します。Cisco Crosswork からのデバイスのプロトコルの更新 を参照してください。

  4. デバイスで gNMI を有効にします。gNMI用のデバイス設定 を参照してください。

  5. デバイスで gNMI バンドルを有効にします。「IOS XR の gNMI バンドルの設定」を参照してください。

  6. デバイスで証明書とデバイスキーを設定します。デバイスへの証明書のインポートとインストール を参照してください。

デバイス証明書の生成

この項では、OpenSSL を使用して証明書を作成する方法について説明します。

証明書を生成する手順は、Open SSL と Microsoft で検証済みです。この手順では、Open SSL を使用してデバイス証明書を生成する手順について説明しました。


（注）  
Open SSL または Microsoft 以外のユーティリティを使用してデバイス証明書を生成するには、シスコサポートチームにお問い合わせください。

  1. rootCA 証明書の作成

    # openssl genrsa -out rootCA.key
# openssl req -subj /C=/ST=/L=/O=/CN=CrossworkCA -x509 -new -nodes -key rootCA.key -sha256 -out rootCA.pem -days 1024

    上記のコマンドでは、days 属性によって証明書の有効期間が決まります。最小値は 30 日です。つまり、30 日ごとに証明書を更新する必要があります。値を 365 日に設定することをお勧めします。

  2. デバイスキーと証明書の作成

    
# openssl genrsa -out device.key
# openssl req -subj /C=/ST=/L=/O=/CN=Crosswork -new -key device.key -out device.csr
# openssl x509 -req -extfile <(printf "subjectAltName=IP.0: 10.58.56.18") -in device.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -sha256 -out device.crt -days 1024

    複数のデバイスがある場合、複数のデバイス証明書を作成する代わりに、subjectAltName に複数のデバイス IP アドレスをカンマで区切って指定できます。 

    # openssl x509 -req -extfile <(printf "subjectAltName=IP.0: 10.58.56.18, IP.1: 10.58.56.19, IP.2: 10.58.56.20 ..... ") -in device.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -sha256 -out device.crt -days 1024

  3. 証明書が作成され、予期される SAN の詳細が含まれているかどうかの確認

    # openssl x509 -in device.crt -text -noout

    次に、出力例を示します。

    Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            66:38:0c:59:36:59:da:8c:5f:82:3b:b8:a7:47:8f:b6:17:1f:6a:0f
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = rootCA
        Validity
            Not Before: Oct 28 17:44:28 2021 GMT
            Not After : Aug 17 17:44:28 2024 GMT
        Subject: CN = Crosswork
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:c6:25:8a:e8:37:7f:8d:1a:7f:fa:e2:d6:10:0d:
                    b8:e6:2b:b0:b0:7e:ab:c9:f9:14:a3:4f:2e:e6:30:
                    97:f4:cd:d6:11:7d:c0:a6:9b:43:83:3e:26:0f:73:
                    42:89:3c:d7:62:7b:04:af:0b:16:67:4c:8e:60:05:
                    cc:dd:99:37:3f:a4:17:ed:ff:28:21:20:50:6f:d9:
                    be:23:78:07:dc:1e:31:5e:5f:ca:54:27:e0:64:80:
                    03:33:f1:cd:09:52:07:6f:13:81:1b:e1:77:e2:08:
                    9f:b4:c5:97:a3:71:e8:c4:c8:60:18:fc:f3:be:5f:
                    d5:37:c6:05:6e:9e:1f:65:5b:67:46:a6:d3:94:1f:
                    38:36:54:be:23:28:cc:7b:a1:86:ae:bd:0d:19:1e:
                    77:b7:bd:db:5a:43:1f:8b:06:4e:cd:89:88:e6:45:
                    0e:e3:17:b3:0d:ba:c8:25:9f:fc:40:08:87:32:26:
                    69:62:c9:57:72:8a:c2:a1:37:3f:9d:37:e9:69:33:
                    a5:68:0f:8f:f4:31:a8:bc:34:93:a3:81:b9:38:87:
                    2a:87:a3:4c:e0:d6:aa:ad:a7:5c:fb:98:a2:71:15:
                    68:e7:8d:0f:71:9a:a1:ca:10:81:f8:f6:85:86:c1:
                    06:cc:a2:47:16:89:ee:d1:90:c9:51:e1:0d:a3:2f:
                    9f:0b
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                IP Address:10.58.56.18
    Signature Algorithm: sha256WithRSAEncryption
         01:41:2c:91:0b:a1:10:8a:11:1a:95:36:99:2c:27:31:d3:7d:
         e9:4b:29:56:c3:b7:00:8c:f4:39:d2:8c:50:a4:da:d4:96:93:
         eb:bb:71:e3:70:d3:fe:1f:97:b2:bc:5c:f8:f4:65:ed:83:f7:
         67:56:db:0f:67:c2:3d:0c:e7:f8:37:65:1d:11:09:9a:e3:42:
         bc:c6:a0:31:7c:1f:d7:5e:c6:86:72:43:a8:c1:0c:70:33:60:
         dc:14:5b:9d:f3:ab:3d:d5:d2:94:90:1c:ba:fd:80:4d:22:e3:
         31:93:c7:16:5f:85:20:38:ad:36:b9:1a:e0:89:8e:06:8c:f8:
         cd:55:cc:a1:89:d3:91:7f:66:61:a3:40:71:c2:1e:ee:3b:80:
         37:af:73:5e:8e:0d:db:4b:49:da:a6:bd:7d:0a:aa:9e:9a:9e:
         fa:ed:05:25:08:f2:4d:cd:2f:63:55:cf:be:b1:5d:03:c2:b3:
         32:bf:f4:7b:1a:10:b9:5e:69:ac:77:5e:4a:4f:85:e3:7f:fe:
         04:df:ce:3e:bb:28:8f:e3:bf:1a:f9:0f:94:18:08:86:7d:59:
         57:71:0a:97:0d:86:9c:63:e7:0e:48:7d:f0:0e:1d:67:ff:9b:
         1d:1b:05:25:c8:c3:1f:f4:52:0f:e1:bf:86:d7:ec:47:10:bd:
         94:cf:ca:e2
gNMI 証明書の設定

Crosswork Data Gateway は gNMI クライアントとして機能し、デバイスは gNMI サーバーとして機能します。Crosswork Data Gateway は、信頼チェーンを使用してデバイスを検証します。すべてのデバイスにグローバルな信頼チェーンがあることが期待されます。信頼チェーンが複数ある場合は、すべてのデバイス信頼チェーン（単一または複数のベンダー）を 1 つの .pem ファイルに追加し、この .pem ファイルを Crosswork 証明書管理の UI にアップロードします。


（注）  
Crosswork にアップロードできる gNMI 証明書は 1 つのみです。

gNMI 証明書を追加するには、次の手順を実行します。

手順

ステップ 1

Cisco Crosswork の UI から、[管理（Administration）] > [証明書管理（Certificate Management）] に移動します。

ステップ 2

[+] アイコンをクリックして証明書を追加します。

ステップ 3

[証明書の追加（Add certificate）] ウィンドウで、次の詳細情報を入力します。

  • [証明書名（Certificate name）]：証明書の名前を入力します。

  • [証明書のロール（Certificate role）]：ドロップダウンリストから [デバイス gNMI 通信（Device gNMI Communication）] を選択します。

  • [デバイス信頼チェーン（Device trust chain）]：rootCA ファイルの場所までローカルファイルシステムを参照し、そのファイルをアップロードします。

図 30. [証明書の追加（Add Certificate）] ウィンドウ
[証明書の追加（Add Certificate）] ウィンドウ

（注）  

 

gNMI 証明書がすでに設定されている場合で、別の信頼チェーンを使用してデバイスをオンボーディングするときは、既存の .pem ファイルを更新して新しい CA の詳細を含めます。リストから既存の gNMI 証明書を選択し、[編集（Edit）] アイコンをクリックして、新しい .pem ファイルをアップロードします。

ステップ 4

[保存（Save）] をクリックします。

gNMI 証明書が追加されると、設定済みの証明書のリストに表示されます。

図 31. 証明書管理ウィンドウ
[証明書（Certificate）] ウィンドウ
デバイスへの証明書のインポートとインストール

このセクションでは、IOS XR および XE デバイスに証明書をインポートしてインストールする方法について説明します。証明書とトラストポイントは、セキュア gNMI サーバーにのみ必要です。

Cisco IOS XR デバイスの証明書

Cisco IOS XR デバイスに証明書をインストールするには、次の手順を実行します。

  1. rootCA.pem、device.key、および device.crt を /tmp フォルダの下のデバイスにコピーします。

  2. IOS XR デバイスにログインします。

  3. run コマンドを使用して VM シェルを開始します。

    RP/0/RP0/CPU0:xrvr-7.2.1#run

  4. 次のディレクトリに移動します。

    cd /misc/config/grpc

  5. 次のファイルの内容を作成または置換します。


    （注）  
    デバイスで TLS が以前に有効になっていた場合は、次のファイルがすでに存在します。その場合、以下で説明するようにこれらのファイルの内容を置き換えます。初めて行う場合は、デバイスで TLS を有効にし、/tmp フォルダからこのフォルダにファイルをコピーします。

    • ems.pem with device.crt

    • ems.key with device.key

    • ca.cert with rootCA.pem

  6. 変更を有効にするには、デバイスで TLS を再起動します。この手順では、「no-tls」コマンドを使用して TLS を無効にし、デバイスで「no no-tls」設定コマンドを使用して再度有効にします。

Cisco IOS XE デバイスの証明書

次に、Cisco IOS XE デバイスに証明書をインストールする例を示します。

# Send:
Device# configure terminal
Device(config)# crypto pki import trustpoint1 pem terminal password password1 
 
# Receive:
% Enter PEM-formatted CA certificate.
% End with a blank line or "quit" on a line by itself.
 
# Send:
# Contents of rootCA.pem, followed by newline + 'quit' + newline:
-----BEGIN CERTIFICATE-----
<snip>
-----END CERTIFICATE-----
quit
 
# Receive:
% Enter PEM-formatted encrypted private General Purpose key.
% End with "quit" on a line by itself.
 
# Send:
# Contents of device.des3.key, followed by newline + 'quit' + newline:
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,D954FF9E43F1BA20
<snip>
-----END RSA PRIVATE KEY-----
quit
 
# Receive:
% Enter PEM-formatted General Purpose certificate.
% End with a blank line or "quit" on a line by itself.
 
# Send:
# Contents of device.crt, followed by newline + 'quit' + newline:
-----BEGIN CERTIFICATE-----
<snip>
-----END CERTIFICATE-----
quit
 
# Receive:
% PEM files import succeeded.
Device(config)#
 
# Send:
Device(config)# crypto pki trustpoint trustpoint1
Device(ca-trustpoint)# revocation-check none
Device(ca-trustpoint)# end
Device#
Cisco Crosswork からのデバイスのプロトコルの更新

Cisco Crosswork で gNMI 証明書を設定したら、Cisco Crosswork の UI（[デバイス管理（Device Management）] > [ネットワークデバイス（Network Devices）]）から、または .csv ファイルでプロトコルの詳細を GNMI_SECURE ポートとして指定して、デバイスのセキュアプロトコルの詳細を更新します。

次の図に、デバイスの更新されたセキュアプロトコルの詳細を示します。

図 32. [デバイスの詳細の編集（Edit Device Details）] ウィンドウ
[デバイスの詳細の編集（Edit Device Details）] ウィンドウ
gNMI用のデバイス設定

このセクションでは、gNMI ベースのテレメトリデータ収集をサポートするように IOS XR および IOS XE デバイスを設定する手順について説明します。

Cisco IOS XR デバイス

  1. HTTP/2 接続で gRPC を有効にします。

    Router#configure
Router(config)#grpc
Router(config-grpc)#port <port-number>

    ポート番号の範囲は 57344 ～ 57999 です。ポート番号が使用できない場合は、エラーが表示されます。

  2. セッション パラメータを設定します。

    Router(config)#grpc{ address-family | dscp | max-request-per-user | max-request-total | max-streams | 
max-streams-per-user | no-tls | service-layer | tls-cipher | tls-mutual | tls-trustpoint | vrf }

    値は次のとおりです。

    • address-family：アドレスファミリ識別子タイプを設定します。

    • dscp：送信された gRPC で QoS マーキング DSCP を設定します。

    • max-request-per-user：ユーザーあたりの同時要求の最大数を設定します。

    • max-request-total：合計同時要求の最大数を設定します。

    • max-streams：同時 gRPC 要求の最大数を設定します。サブスクリプションの上限は 128 要求です。デフォルトは 32 要求です。

    • max-streams-per-user：ユーザーあたりの同時 gRPC 要求の最大数を設定します。サブスクリプションの上限は 128 要求です。デフォルトは 32 要求です。

    • no-tls：トランスポート レイヤ セキュリティ（TLS）を無効化します。TLS はデフォルトで有効になっています。

    • service-layer：gRPC サービス レイヤの設定を有効にします。

    • tls-cipher：gRPC TLS 暗号スイートを有効にします。

    • tls-mutual：相互認証を設定します。

    • tls-trustpoint：トラストポイントを設定します。

    • vrf：サーバー VRF を有効にします。

  3. サードパーティ製アプリケーションのトラフィック保護（TPA）を有効にします。

    tpa
vrf default
  address-family ipv4
   default-route mgmt
   update-source dataports MgmtEth0/RP0/CPU0/0
Cisco IOS XE デバイス

次に、gNMI サーバを非セキュア モードで有効にする例を示します。

Device# configure terminal
Device(config)# gnmi-yang
Device(config)# gnmi-yang server
Device(config)# gnmi-yang port 50000 <The default port is 50052.>
Device(config)# end
Device

次に、gNMI サーバをセキュア モードで有効にする例を示します。

Device# configure terminal
Device(config)# gnmi-yang server
Device(config)# gnmi-yang secure-server
Device(config)# gnmi-yang secure-trustpoint trustpoint1
Device(config)# gnmi-yang secure-client-auth
Device(config)# gnmi-yang secure-port 50001 <The default port is 50051.>
Device(config)# end
Device
IOS XR の gNMI バンドルの設定

IOS XR では、SubscribeResponse メッセージの通知メッセージに含まれるいくつかの更新メッセージを結合するために、gNMI バンドルが実装されています。これらのメッセージは、IOS XR デバイスに送信されます。更新メッセージをバンドルするには、IOS XR デバイスでバンドルを有効にし、メッセージのサイズを指定する必要があります。

始める前に

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

  • IOS XR リリースバージョン 7.81 以降では、gNMI バンドル機能がサポートされています。バンドル機能の動作の詳細については、『Programmability Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.8.x』を参照してください。

  • gNMI バンドル機能は、デバイスからのみ構成できます。このオプションは、Crosswork インターフェイスでは使用できません。

手順

ステップ 1

次のコマンドを使用して、バンドル機能を有効にします。

telemetry model-driven
 gnmi
  bundling
gNMI バンドル機能は、デフォルトで無効になっています。

ステップ 2

次のコマンドを使用して、gNMI バンドルサイズを指定します。

telemetry model-driven
 gnmi
  bundling
   size  <1024-65536>
デフォルトのバンドルサイズは、32768 バイトです。

重要

 

（N - 1）インスタンスを処理した後で、メッセージサイズがバンドルサイズよりも小さい場合、もう 1 つのインスタンスが許可される可能性があり、結果としてバンドルサイズを超えます。
次のタスク
次を使用して、バンドル機能が構成されていることを確認します。 
RP/0/RP0/CPU0:R0(config)#telemetry model-driven
RP/0/RP0/CPU0:R0(config-model-driven)#gnmi ?
  bundling   gNMI bundling of telemetry updates
  heartbeat  gNMI heartbeat
  <cr>
RP/0/RP0/CPU0:R0(config-model-driven)#gnmi bundling ?
  size  gNMI bundling size (default: 32768)
  <cr>
RP/0/RP0/CPU0:R0(config-model-driven)#gnmi bundling
RP/0/RP0/CPU0:R0(config-gnmi-bdl)#size ?
  <1024-65536>  gNMI bundling size (bytes)

Cisco Crosswork UI からの収集ジョブの作成

収集ジョブを作成するには、次の手順を実行します。


（注）  

Crosswork ネットワークコントローラ の UI ページを使用して作成した収集ジョブは、1 回のみパブリッシュできます。

始める前に

収集したデータを保存するためのデータ送信先が作成されている（アクティブになっている）ことを確認します。また、データを収集する予定のセンサーパスと MIB の詳細を確認します。

手順

ステップ 1

メインメニューから、[管理（Administration）] > [収集ジョブ（Collection Jobs）] > [一括ジョブ（Bulk Jobs）] に移動します。

ステップ 2

左側のペインで [追加（Add）] アイコン ボタンをクリックします。

ステップ 3

[新規の収集ジョブ（New Collection Job）] ページで、次のフィールドに値を入力します。

図 33. [新規収集ジョブ（New Collection Job）] ウィンドウ
[ジョブの詳細（Job Details）] ウィンドウ

  • [アプリケーションID（Application Id）]：アプリケーションの一意の識別子。

  • [コンテキストID（Context Id）]：すべての収集ジョブでアプリケーションのサブスクリプションを識別するための一意の識別子。

  • [コレクタータイプ（Collector type）]：収集のタイプ（CLI または SNMP）を選択します。

[次へ（Next）] をクリックします。

ステップ 4

データを収集するデバイスを選択します。デバイスタグに基づいて選択することも、手動で選択することもできます。[次へ（Next）] をクリックします。

図 34. [デバイスの選択（Select Devices）] ウィンドウ
[デバイスの選択（Select Devices）] ウィンドウ

ステップ 5

（CLI での収集の場合にのみ適用）次のセンサーの詳細を入力します。

図 35. CLI パスの [センサーの詳細（Sensor Details）] ウィンドウ
[センサーの詳細（Sensor Details）] ウィンドウ

  • [データ送信先の選択（Select data destination）] ドロップダウンリストからデータ送信先を選択します。

  • 左側の [センサータイプ（Sensor types）] ペインからセンサータイプを選択します。

[CLIパス（CLI path）] を選択した場合は、[追加（Add）] アイコン ボタンをクリックして、[CLIパスの追加（Add CLI Path）] ダイアログボックスに次のパラメータを入力します。

図 36. [CLIパスの追加（Add CLI Path）] ダイアログボックス
[CLIパスの追加（Add CLI Path）] ダイアログボックス

  • [収集パターン（Collection Cadence）]：プッシュまたはポーリングパターンを秒単位で指定します。

  • [コマンド（Command）]：CLI コマンド

  • [トピック（Topic）]：出力先に関連付けられているトピック。

    （注）  

     
    外部 gRPC サーバーを使用する場合、トピックは任意の文字列にできます。

[デバイスパッケージ（Device package）] を選択した場合は、[追加（Add）] アイコン ボタンをクリックし、[デバイスパッケージセンサーの追加（Add Device Package Sensor）] ダイアログボックスに次のパラメータの値を入力します。

図 37. [デバイスパッケージセンサーの追加（Add Device Package Sensor）] ダイアログボックス
[デバイスパッケージセンサーの追加（Add Device Package Sensor）] ダイアログボックス

  • [収集パターン（Collection Cadence）]：プッシュまたはポーリングパターンを秒単位で指定します。

  • [デバイスパッケージ名（Device package name）]：デバイスパッケージの作成時に使用するカスタム XDE デバイスパッケージの ID。

  • [関数名（Function name）]：カスタム XDE デバイスパッケージ内の関数名。

  • [トピック（Topic）]：出力先に関連付けられているトピック。

  • パラメータのキーと文字列の値を入力します。

[保存（Save）] をクリックします。

ステップ 6

（SNMP での収集の場合にのみ適用）次のセンサーの詳細を入力します。

図 38. SNMP パスの [センサーの詳細（Sensor Details）] ウィンドウ
[センサーの詳細（Sensor Details）] ウィンドウ

  • [データ送信先の選択（Select data destination）] ドロップダウンリストからデータ送信先を選択します。

  • 左側の [センサータイプ（Sensor types）] ペインからセンサータイプを選択します。

[SNMP MIB] を選択した場合は、[追加（Add）] アイコン ボタンをクリックして、[SNMP MIB の追加（Add SNMP MIB）] ダイアログボックスに次のパラメータを入力します。

図 39. [SNMP MIBの追加（Add SNMP MIB）] ダイアログボックス
[SNMP MIBの追加（Add SNMP MIB）] ダイアログボックス

  • [収集パターン（Collection Cadence）]：プッシュまたはポーリングパターンを秒単位で指定します。

  • OID

  • [操作（Operation）]：リストから操作を選択します。

  • [トピック（Topic）]：出力先に関連付けられているトピック。

[デバイスパッケージ（Device package）] を選択した場合は、[追加（Add）] アイコン ボタンをクリックし、[デバイスパッケージセンサーの追加（Add Device Package Sensor）] ダイアログボックスに次のパラメータの値を入力します。

図 40. [デバイスパッケージセンサーの追加（Add Device Package Sensor）] ダイアログボックス
[デバイスパッケージセンサーの追加（Add Device Package Sensor）] ダイアログボックス

  • [収集パターン（Collection Cadence）]：プッシュまたはポーリングパターンを秒単位で指定します。

  • [デバイスパッケージ名（Device package name）]：デバイスパッケージの作成時に使用するカスタムデバイスパッケージの ID。

  • [関数名（Function name）]：カスタムデバイスパッケージ内の関数名。

  • [トピック（Topic）]：出力先に関連付けられているトピック。

  • パラメータのキーと文字列の値を入力します。

[保存（Save）] をクリックします。

ステップ 7

[収集ジョブの作成（Create Collection Job）] をクリックします。

（注）  

 

外部の Kafka 接続先（つまり安全でない Kafka）に対して収集ジョブが送信されると、Kafka へのディスパッチジョブは接続に失敗します。コレクターのログに「org.apache.kafka.common.errors.TimeoutException: Topic cli-job-kafka-unsecure not present in metadata after 60000 ms」というエラーが表示されます。Kafka のログには「SSL authentication error "[2021-01-08 22:17:03,049] INFO [SocketServer brokerId=0] Failed authentication with /80.80.80.108 (SSL handshake failed) (org.apache.kafka.common.network.Selector)」というエラーが表示されます。

これは、外部の Kafka VM でポートがブロックされているために発生します。次のコマンドを使用して、ポートが Kafka Docker/サーバーポートでリッスンしているかどうかを確認できます。

netstat -tulpn

Kafka サーバーの問題を修正し、Kafka サーバープロセスを再起動します。

収集ジョブのモニター

[収集ジョブ（Collection Jobs）] ページから、Crosswork ネットワークコントローラ に登録されているすべての Crosswork Data Gateway インスタンスで現在アクティブな収集ジョブのステータスをモニターできます。

Cisco Crosswork の UI の左側のナビゲーションバーで、[管理（Administration）] > [収集ジョブ（Collection Jobs）] を選択します。

この左側のペインには、すべてのアクティブな収集ジョブが、ステータス、アプリケーション ID、コンテキスト ID、およびアクションとともに一覧表示されます。[アクション（Actions）] ドロップダウンでは、次の操作が可能です。

  • [削除（Delete）]：収集ジョブを削除します。

  • [更新（Refresh）]：収集ジョブのステータスと、ジョブに関連付けられているタスクを更新します。

[ジョブの詳細（Job Details）] ペインには、左側ペインの特定のジョブに関連付けられているすべての収集タスクの詳細が表示されます。[収集ジョブ（Collection Jobs）] ペインの収集ジョブの全体的なステータスは、[ジョブの詳細（Jobs Details）] ペインのすべての収集タスクの集約ステータスです。

[収集ジョブ（Collection Jobs）] ペインでジョブを選択すると、[ジョブの詳細（Job Details）] ペインに次の詳細が表示されます。

  • 収集ジョブに関連付けられたアプリケーション名とコンテキスト。

  • 収集ジョブのステータス。


    （注）  

    • デバイスが Crosswork Data Gateway に接続された後にそのデバイスに関連付けられている収集タスクのステータスは、[不明（Unknown）] になります。

    • 次のいずれかの理由で、ジョブのステータスが [不明（Unknown）] になる可能性があります。

      • Crosswork Data Gateway がまだそのステータスを報告していない。

      • Crosswork Data Gateway と Cisco Crosswork 間の接続が失われた。

      • Crosswork Data Gateway は収集ジョブを受信したが、実際の収集はまだ保留中になっている。たとえば、トラップが Crosswork Data Gateway のサウスバウンド インターフェイスに送信されていない場合や、デバイスがテレメトリ更新を送信していない場合などです。

      • 監視している SNMP トラップ収集ジョブのトラップ条件が発生していない。たとえば、リンクアップまたはリンクダウンの遷移を探していて、コレクターが確立されてからリンク状態が変更されていない場合、状態は [不明（Unknown）] として報告されます。したがって、トラップベースのコレクションが機能していることを検証するには、実際にトラップをトリガーする必要があります。

    • 収集ジョブが処理された後、処理が成功した場合はステータスが [成功（Successful）] に変わり、それ以外の場合は [失敗（Failed）] に変わります。

    • 収集ジョブが低下状態の場合、その原因の 1 つとして、デバイスへの静的ルートが Crosswork Data Gateway から消去されていることが考えられます。

    • エラー状態にある宛先へのコレクションは停止しません。宛先状態はバックグラウンドで識別されます。宛先がエラー状態の場合、エラーカウントがインクリメントされます。[ディストリビューション（Distribution）] ステータスに表示されるエラーメッセージをドリルダウンし、それぞれのコレクターログを調べて問題を特定して解決します。

    • Cisco Crosswork Health Insights：KPI ジョブは、拡張 Crosswork Data Gateway インスタンスにマッピングされたデバイスでのみ有効にする必要があります。標準の Crosswork Data Gateway インスタンスにマッピングされているデバイスで KPI ジョブを有効にすると、[ジョブの詳細（Jobs Details）] ペインで収集ジョブのステータスが [低下（Degraded）]、収集タスクのステータスが [失敗（Failed）] として報告されます。

  • REST API 要求で渡す収集ジョブのジョブ設定。ジョブの設定を表示するには、[設定の詳細（Config Details）] の横にある アイコンをクリックします。Crosswork ネットワークコントローラ では、次の 2 つのモードで設定を表示できます。

    • ビュー モード

    • テキストモード

  • 収集タイプ

  • 収集ジョブの最終変更日時。

  • [収集（x）（Collections (x)）]：x は、センサーパスによってデバイスにまたがる要求された収集の入力を指します。対応する [（y）問題（(y) Issues）] は [不明（UNKNOWN）] 状態または [失敗（FAILED）] 状態の入力収集の数です。

  • [配布（x）（Distributions (x)）]：x は、センサーパスによってデバイスにまたがる要求された出力収集を指します。対応する [（y）問題（(y) Issues）] は [不明（UNKNOWN）] 状態または [失敗（FAILED）] 状態の出力収集の数です。

Crosswork ネットワークコントローラ は、収集と配布に関する次の詳細も表示します。

フィールド

説明

収集/配布ステータス（Collection/Distribution Status）

収集/配布のステータス。Crosswork Data Gateway から変更ベースで報告されます。詳細については、[収集/配信ステータス（Collection/Distribution Status）] の横にある をクリックします。

ホスト名（Hostname）

収集ジョブが関連付けられているデバイスのホスト名。

デバイス ID（Device Id）

データの収集元のデバイスの一意の識別子。

センサーデータ（Sensor Data）

センサーパス

収集/配布の概要を表示するには、 をクリックします。センサーデータの概要ポップアップから [クリップボードにコピー（Copy to Clipboard）] をクリックしてセンサーデータをコピーできます。

収集/配布メトリックの概要を表示するには、 をクリックします。メトリックはパターンベース、つまりデフォルトでは 10分 ごとに 1 回報告されます。収集に関する次のメトリックが表示されます。

  • last_collection_time_msec

  • total_collection_message_count

  • last_device_latency_msec

  • last_collection_cadence_msec

収集に関する次のメトリックが表示されます。

  • total_output_message_count

  • last_destination_latency_msec

  • last_output_cadence_msec

  • last_output_time_msec

  • total_output_bytes_count

接続先（Destination）

ジョブのデータ接続先。

最後のステータス変更の報告時刻（Last Status Change Reported Time）

デバイスセンサーペアの最後のステータス変更が Crosswork Data Gateway から報告された日時。


（注）  

  • Create Failed エラーは、N 台のデバイスのうちの一部のデバイスの設定に失敗したことを示します。ただし、収集は正常に設定されたデバイスで行われます。Control Status API を使用して、このエラーの原因となっているデバイスを特定できます。

  • NSO エラーが原因で特定のデバイスでジョブの作成が失敗した場合は、NSO エラーを修正した後、デバイスの管理状態を手動で最初に [ダウン（Down）] にしてから [アップ（Up）] に変更する必要があります。ただし、これを行うと、デバイス上の収集がリセットされます。

（注）  

作成または削除手順が失敗したときに発生するエラーは、別のポップアップ画面に表示されます。エラーの詳細を表示するには、ジョブステータスの横にある をクリックします。

  • 同じペイロードで PUT 収集ジョブ API を使用してジョブを再作成することもできます。

イベントベースの収集ジョブの収集ステータス

  1. データの収集が成功すると、[収集ジョブ（Collection Jobs）] ペインで収集ジョブのステータスが [不明（Unknown）] から [成功（Success）] に変わります。

  2. デバイスが Crosswork Data Gateway から切断されると、対応するすべての収集ジョブが削除され、[収集ジョブ（Collection Jobs）] ペインに収集ジョブのステータスが [成功（Success）] と表示されます。[ジョブの詳細（Job Details）] ペインに表示されるデバイスまたは収集タスクはありません。

  3. デバイスが Crosswork Data Gateway に接続されると、Crosswork Data Gateway は、ステータスが [不明（Unknown）] に設定されている新しい収集ジョブを受信します。このステータスは、デバイスからイベントを受信した後に [成功（Success）] に変わります。

  4. すでに Crosswork Data Gateway に接続されているデバイスでデバイス設定が誤って更新された場合、Crosswork Data Gateway がジョブとイベントを受信しても、[ジョブの詳細（Jobs Details）] ペインの収集タスクのステータスは変わりません。

  5. デバイスインベントリが誤ったデバイス IP で更新された場合、[ジョブの詳細（Jobs Details）] ペインの収集タスクのステータスは [不明（Unknown）] になります。

収集ジョブの削除

システムジョブ（さまざまな Crosswork アプリケーションによって作成されたデフォルトのジョブ）は、問題が発生するため削除しないでください。Health Insights によって作成されたジョブは、展開された収集ジョブを削除する KPI プロファイルを無効にすることによってのみ削除する必要があります。収集ジョブを削除すると、関連する収集タスクも削除されます。

[収集ジョブ（Collection Jobs）] ページからは、外部収集ジョブを削除するには、次の手順を使用します。収集ジョブを削除するには、次の手順を実行します。

手順

ステップ 1

メインメニューから、[管理（Administration）] > [収集ジョブ（Collection Jobs）] に移動します。

ステップ 2

[一括ジョブ（Bulk Jobs）] タブまたは [パラメータ化されたジョブ（Parametrized Jobs）] タブのいずれかを選択します。

ステップ 3

左側の [収集ジョブ（Collection Jobs）] ペインで、削除する収集ジョブを選択します。

ステップ 4

対応する行で [その他（More）] アイコン をクリックし、[削除（Delete）] を選択します。[収集ジョブの削除（Delete Collection Job）] ウィンドウが表示されます。

ステップ 5

確認を求められたら、[削除（Delete）] をクリックします。

Crosswork Data Gateway のトラブルシューティング

この項では、Crosswork Network Controller の UI から使用できるさまざまなトラブルシューティングのオプションについて説明します。

図 41. データゲートウェイ - トラブルシューティング
データゲートウェイ - トラブルシューティング

データゲートウェイ VM のインタラクティブコンソールから使用できるトラブルシューティングオプションの詳細については、Crosswork Data Gateway VM のトラブルシューティングを参照してください。

接続先への接続の確認

データゲートウェイから接続先への接続を確認するには、[トラブルシューティング（Troubleshooting）] メニューの [Ping] オプションと [トレースルート（Traceroute）] オプションを使用します。


（注）  
接続先を正常に ping するには、ネットワークで ping トラフィックを有効にする必要があります。

  1. [管理（Administration）] > [Data Gatewayの管理（Data Gateway Management）] > [データゲートウェイ（Data gateways）] に移動します。

  2. 接続を確認するデータゲートウェイの名前をクリックします。

  3. [Crosswork Data Gateway の詳細（Crosswork Data Gateway details）] ページの右上隅で、[アクション（Actions）] をクリックし、[Ping] または [トレースルート（Traceroute）] を選択します。

    • [Ping]：[パケット数（Number of Packets）] フィールドと [接続先アドレス（Destination Address）] フィールドに詳細を入力し、[Ping] をクリックします。

    • [トレースルート（Traceroute）]：[接続先アドレス（Destination Address）] に入力し、[トレースルート（Traceroute）] をクリックします。

  4. 接続先が到達可能な場合、Cisco Crosswork は同じウィンドウに [Ping] または [トレースルート（Traceroute）] のテストの詳細を表示します。

サービスメトリックのダウンロード

Cisco Crosswork の UI からデータゲートウェイのすべての収集ジョブのメトリックをダウンロードするには、次の手順を実行します。

手順

ステップ 1

[管理（Administration）] > [データゲートウェイの管理（Data Gateway Management）] > [データゲートウェイインスタンス（Data gateway instances）] に移動します。

ステップ 2

サービスメトリックをダウンロードするデータゲートウェイの名前をクリックします。

ステップ 3

[Crosswork Data Gateway の詳細（Crosswork Data Gateway details）] ページの右上隅で、[アクション（Actions）] > [サービスメトリックのダウンロード（Download Service Metrics）] をクリックします。

ステップ 4

パスフレーズを入力します。

（注）  

 

このパスフレーズを必ずメモしておいてください。このパスフレーズは、後でファイルを復号するために使用します。

ステップ 5

[サービスメトリックのダウンロード（Download Service Metrics）] をクリックします。ファイルは、システムのデフォルトのダウンロードフォルダに暗号化された形式でダウンロードされます。

ステップ 6

ダウンロードが完了したら、次のコマンドを実行して復号します。

（注）  

 

ファイルを復号するには、openssl バージョン 1.1.1i を使用する必要があります。openssl version コマンドを使用して、システムの openssl バージョンを確認します。

openssl enc -d -aes-256-ctr -pbkdf2 -md sha3-512 -iter 100000 -in <service metrics file> -out <decrypted filename> -pass pass:<encrypt string>

Showtech ログのダウンロード

Cisco Crosswork の UI から showtech ログをダウンロードする手順を実行します。


（注）  

データゲートウェイが [エラー（ERROR）] 状態の場合、Showtech ログは UI から収集できません。データゲートウェイが [低下（DEGRADED）] 状態の場合、OAM-Manager サービスが実行されており、低下していなければ、ログを収集できます。

手順

ステップ 1

[管理（Administration）] > [データゲートウェイの管理（Data Gateway Management）] > [データゲートウェイ（Data gateways）] に移動します。

ステップ 2

showtech をダウンロードするデータゲートウェイの名前をクリックします。

ステップ 3

Crosswork Data Gateway の詳細ページの右上隅にある [アクション（Actions）] をクリックし、[Showtech のダウンロード（Download Showtech）] をクリックします。

図 42. データゲートウェイ - Showtech のダウンロード
データゲートウェイ - Showtech のダウンロード

ステップ 4

パスフレーズを入力します。

（注）  

 

このパスフレーズを必ずメモしておいてください。showtech ファイルを復号するには、このパスフレーズを後で入力する必要があります。
図 43. [Showtechのダウンロード（Download Showtech）] ポップアップウィンドウ
[Showtechのダウンロード（Download Showtech）] ポップアップウィンドウ

ステップ 5

[Showtech のダウンロード（Download Showtech）] をクリックします。showtech ファイルは暗号化された形式でダウンロードされます。

（注）  

 

システムの使用時間によっては、showtech ファイルのダウンロードに数分かかる場合があります。

ステップ 6

ダウンロードが完了したら、次のコマンドを実行して復号します。

（注）  

 

ファイルを復号するには、OpenSSL バージョン 1.1.1i を使用する必要があります。システムの OpenSSL バージョンを確認するには、openssl version コマンドを使用します。

MAC でファイルを復号するには、OpenSSL 1.1.1+ をインストールする必要があります。これは、LibreSSL の openssl コマンドが OpenSSL の openssl コマンドでサポートされているすべてのスイッチはサポートしていないためです。

openssl enc -d -aes-256-ctr -pbkdf2 -md sha3-512 -iter 100000 -in <showtech file> -out <decrypted filename> -pass pass:<encrypt string>

データゲートウェイ VM の再起動

Crosswork Network Controller の UI からデータゲートウェイを再起動するには、次の手順を実行します。


（注）  

データゲートウェイを再起動すると、再び動作するまで機能が一時停止します。

手順

ステップ 1

[管理（Administration）] > [データゲートウェイの管理（Data Gateway Management）] > [データゲートウェイ（Data gateways）] に移動します。

ステップ 2

再起動するデータゲートウェイの名前をクリックします。

ステップ 3

Crosswork Data Gateway の詳細ページの右上隅にある [アクション（Actions）] をクリックし、[再起動（Reboot）] をクリックします。

図 44. [データゲートウェイ（Data Gateway）] - [再起動（Reboot）]
[データゲートウェイ（Data Gateway）] - [再起動（Reboot）]

ステップ 4

[ゲートウェイの再起動（Reboot Gateway）] をクリックします。

図 45. [ゲートウェイの再起動（Reboot Gateway）] ポップアップウィンドウ
[ゲートウェイの再起動（Reboot Gateway）] ポップアップウィンドウ

再起動が完了したら、[管理（Administration）] > [データゲートウェイの管理（Data Gateway Management）] > [データゲートウェイインスタンス（Data Gateway Instances）] ウィンドウでデータゲートウェイの動作ステータスを確認します。

Crosswork Data Gateway コンポーネントのログレベルの変更

Cisco Crosswork の UI には、Crosswork Data Gateway のコンポーネント（コレクター（cli-collector）やインフラサービス（oam-manager）など）のログレベルを変更するオプションがあります。ログレベルの変更は、変更を加えるデータゲートウェイにのみ適用されます。


（注）  

オフロードサービスのログレベルの変更はサポートされていません。

手順

ステップ 1

[管理（Administration）] > [Data Gatewayの管理（Data Gateway Management）] > [データゲートウェイ（Data gateways）] に移動します。

ステップ 2

Crosswork インフラストラクチャ サービスのコレクターのログレベルを変更するデータゲートウェイ名をクリックします。

ステップ 3

[Crosswork Data Gateway の詳細（Crosswork Data Gateway details）] ページの右上隅で、[アクション（Actions）] > [ログレベルの変更（Change Log Level）] をクリックします。

[ログレベルの変更（Change Log Level）] ウィンドウが表示され、各コンテナサービスの現在のログレベルが示されます。

図 46. [ログレベルの変更（Change Log Level）] ウィンドウ
[ログレベルの変更（Change Log Level）] ウィンドウ

ステップ 4

ログレベルを変更するコンテナサービスのチェックボックスをオンにします。

ステップ 5

テーブルの上部にある [ログレベルの変更（Change Log Level）] ドロップダウンリストから、[デバッグ（Debug）]、[トレース（Trace）]、[警告（Warning）]、[情報（Info）]、および [エラー（Error）] からログレベルを選択します。

（注）  

 

すべてのログのログレベルをデフォルトのログレベル（[情報（Info）]）にリセットするには、[デフォルトにリセット（Reset to Default）] をクリックします。

ステップ 6

[保存（Save）] をクリックして変更したログレベルを保存します。

[保存（Save）] をクリックして、コンポーネントのログレベルが正常に変更されたことを示す UI メッセージを表示します。

データゲートウェイを割り当て済み状態から未割り当て状態に移行できない

[プールの作成（Create Pool）] ページの [プールへのデータゲートウェイインスタンスの 追加（Add data gateway instance(s) to pool）] ペインでは、デバイスが接続されていない場合でも、割り当て済み状態のデータゲートウェイを未割り当て状態に移行することはできません。これは、データゲートウェイに VIP が割り当てられており、HA プールから削除できないことを示します。

割り当て済み状態のデータゲートウェイを HA プールから削除するには、次の手順を実行します。

  1. データゲートウェイがスペアとしてまだ存在しない場合にのみ、HA プールにデータゲートウェイを追加します。

  2. 手動フェールオーバーを実行して、割り当て済みデータゲートウェイをスペアにします。

  3. HA プールを更新してスペア数を減らし、スペアデータゲートウェイをプール外に移動します。

回避策： ステップ 2 の手動フェールオーバーに問題があり、データゲートウェイをスペアとして変換できない場合は、HA プールを削除し、別のデータゲートウェイでプールを再作成します。ゲートウェイの削除の詳細については、「Cisco Crosswork からの Crosswork Data Gateway インスタンスの削除」を参照してください。

ネットワークロードバランサがアクティブな Crosswork Data Gateway の誤ったヘルスステータスを表示

プールの作成中に、Crosswork Data Gateway はネットワークロードバランサ（NLB）のヘルスポートを開き、Crosswork Data Gateway のヘルスステータスを示します。ただし、NLB FQDN が eth2 の異なるサブネット上にある IP アドレスに解決される場合、Crosswork Data Gateway は VM に静的ルートを追加します。ネットワーク構成の問題が原因で、静的ルートの組み込みがエラーで失敗する場合があります。Crosswork Data Gateway は失敗を無視し、HA プールを作成します。その結果、Crosswork Data Gateway はデバイスからデータを収集しません。

この問題を解決するには、次の手順を実行します。

手順

ステップ 1

NLB として識別されたシステムにログインし、Crosswork Data Gateway のヘルスステータスを表示します。

ステップ 2

ステータスが異常な場合は、NLB サブネットアドレスが eth1 や eth0 などのインターフェイスと競合しているかどうかを確認します。競合を解決するには、次のいずれかを実行します。

  • NLB IP アドレスを変更し、インフラサービス（oam-manager）を再起動します。

  • 新しいサブネット構成を使用して Crosswork Data Gateway VM を再展開します。

[収集ジョブ（Collection Jobs）] ページの収集ジョブのステータスが [低下（Degraded）] 状態になっている

[収集ジョブ（Collection Jobs）] ページの収集ジョブが [低下（Degraded）] 状態の場合は、サービスのステータスで詳細を確認できます。

サービスステータスを確認するには、[管理（Administration）] > [データゲートウェイの管理（Data Gateway Management）] > [データゲートウェイ（Data gateways）] に移動し、テーブルでプール名をクリックします。プールの詳細ページが開きます。[サービスステータス（Service status）] セクションに移動し、ステータスの詳細を確認します。このセクションには、システム上のサービスとジョブの実行を担うコレクターのリストを示すテーブルが表示されます。

コレクターが [サービスステータス（Service status）] セクションに表示されない場合は、次の手順を使用します。

手順

ステップ 1

インタラクティブコンソールのメインメニューに移動し、[トラブルシューティング（Troubleshooting）] メニューを選択します。

ステップ 2

[すべての非インフラコンテナを削除してVMを再起動する（Remove all Non-Infra Containers and Reboot VM）] メニューを選択します。

ステップ 3

確認ボックスで、[はい（Yes）] を選択します。

ステップ 4

必要に応じて、[サービスステータス（Service status）] セクションでサービスのステータスを確認します。

SNMPv3 エンジン ID が変更されてもデータゲートウェイがデータを収集する

SNMPv3 エンジン ID が変更され、デバイスにダウンタイムまたは到達可能性の問題が発生した場合でも、SNMP コレクターはデータを収集し続けます。理想的には、データゲートウェイは、このような変更中に収集を一時停止する必要があります。

データ収集は、[SNMPV3のUSMエンジンの詳細を強制的に再同期する（Force Re-Sync USM Engine Details for SNMPV3） ] オプションが無効な状態でも続行されます。

この問題を解決するには、[グローバルパラメータ（Global Parameters）] ウィンドウで [SNMPV3のUSMエンジンの詳細を強制的に再同期する（Force Re-Sync USM Engine Details for SNMPV3）] を有効 にするか、デバイスの管理状態を DOWN から UP に変更します。再同期オプションの有効化の詳細については、Crosswork Data Gateway グローバルパラメータの設定を参照してください。

L2VPN ポイントツーポイント サービスが、[監視開始（Monitoring Initiated）] 状態で無応答になる

デバイスがデータゲートウェイとの接続を正しく確立できない場合、gNMI 収集ジョブがエラーで失敗します。その結果、L2VPN ポイントツーポイント サービスはデバイスをモニターできず、Crosswork UI のステータスに [監視開始（Monitoring initiated）] と表示されます。

回避策：データ収集を再開するには、Crosswork Data Gateway とデバイスの接続を解除してから再接続します。詳細については、以下を参照してください。

エラー メッセージ ポップアップが IPv6 アドレスとポート番号を明確に示さない

[デバイス管理（Device Management）] > [ネットワークデバイス（Network Devices）]に移動して、Crosswork Network Controller UI でデバイスのステータス概要を確認できます。

デバイスがエラー状態の場合、[動作状態（Operational state）] 列の状態の横にある情報アイコンにカーソルを合わせると、詳細を確認できます。IPv6 アドレスを持つデバイスを扱う場合、メッセージにはアドレスが 2001:420:284:2004:4:112:165:636:22 という形式で表示され、アドレスとポート番号が組み合わされています。

このような場合、最初のブロックはアドレスを示し、その後にポート番号が続きます。たとえば、[2001:420:284:2004:4:112:165:636] がアドレス、22 がポート番号です。IP アドレスに 8 つのセグメントしかない場合、ポート番号は取得できません。

フェールオーバー中の DAD 障害エラー

フェールオーバー中、プライマリ データ ゲートウェイ（cdg1）はセカンダリゲートウェイ（cdg2）に切り替わり、cdg2 は cdg1 のサウスバウンド IPv6 アドレスを引き継ぎます。cdg2 が検出されると、Crosswok は cdg2 のイベントをログに記録し、IP アドレスが dg1 の設定と重複しているため、重複アドレス検出（DAD）障害を示します。この一時的なエラーは、オペレーティングシステムがインターフェイスから DAD 障害フラグを削除しているときに発生します。オペレーティングシステムがインターフェイスで DAD 障害ステータスをクリアすると、Crosswork はゲートウェイを [アップ（UP）] 状態に移行します。

DAD 障害エラーが 2 分以上続く場合について考えます。この場合、セカンダリ データ ゲートウェイの HA プールのサウスバウンド VIP アドレスを手動で変更し、フェールオーバーをもう一度開始することをお勧めします。

データ ゲートウェイのフェールオーバーが失敗する

いくつかの問題が原因でフェールオーバーが完了しない場合は、少なくとも 1 つのスタンバイインスタンスが NOT_READY 状態であることを確認してから、フェールオーバーを再試行します。

続いてフェールオーバーを開始する前に、スタンバイ データ ゲートウェイが NOT_READY 状態に移行するまで 10 ～ 30 秒待ちます。スタンバイインスタンスが 30 秒後に [アップ（UP）] 状態のままである場合は、データゲートウェイの oam-manager を再起動して、動作状態を [NOT_READY] に復元します。