単一 VM 展開の組み込みコレクター

この章の範囲は、単一の VM での Crosswork Network Controller の展開で使用される組み込みコレクターに限定されます。

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

組み込みコレクター

単一 VM の展開の場合、Crosswork Network Controller は、Cisco Crosswork インフラストラクチャ、組み込みコレクター、および要素管理機能アプリケーションで構成され、これらが 1 つのパッケージにバンドルされています。単一 VM の展開の詳細については、『Cisco Crosswork Network Controller 7.0 Installation Guide』を参照してください。

組み込みコレクターは、コレクターサービスを介してネットワークデータを収集するソリューションです。コレクターは、Kafka または gRPC のいずれかを使用して、Cisco Crosswork または外部接続先、あるいはその両方にデータを転送します。

これらの軽量データコレクターは、Crosswork Network Controller UI で、組み込みコレクターおよびオフロードコンポーネント CAPP ファイルを使用して展開できます。CAPP ファイルの展開には、SNMP、gNMI、syslog、および CLI のコレクターが含まれます。

コレクターがどのように展開されるかの詳細については、『Cisco Crosswork Network Controller 7.0 Installation Guide』を参照してください。

組み込みコレクターの UI にアクセスする方法

組み込みコレクターの管理ビューを開くには、Cisco Crosswork にログインし、左側のナビゲーションバーから [管理（Administration）] > [データコレクターのグローバル設定（Data Collector(s) Global Settings）] を選択します。

図 1. [データコレクターのグローバル設定（Data Collector(s) Global Settings）] ウィンドウ

[データコレクターのグローバル設定（Data Collector(s) Global Settings）] ページでは、左ペインの次のメニューを使用して管理操作を実行できます。

  • [データ送信先（Data Destination）]：コレクターは、テレメトリデータを収集した後、内部または外部のデータ送信先にデータをデポジットします。デフォルトでは、Crosswork_Kafka が内部データ送信先です。外部の宛先は、Cisco Crosswork の UI または API を使用して定義できます。

  • [デバイスパッケージ（Device packages）]：デバイスパッケージを使用することで、コレクターはデータ収集機能をシスコアプリケーションとサードパーティ製デバイスの両方に拡張できます。コレクターは、システムパッケージとカスタムパッケージをサポートします。

    • [システムパッケージ（System packages）]：システムデバイスパッケージには、アプリケーション固有のマニフェストファイルを介して提供される複数のインストールファイルが含まれています。通常、マニフェストファイルは JSON 形式です。

    • [カスタムパッケージ（Custom packages）]：コレクターの UI を使用すると、収集するデータのタイプとデバイスに基づいて、CLI、MIB、SNMP、および集約デバイスのパッケージをアップロードまたはダウンロードできます。

  • [グローバルパラメータ（Global parameters）]：コレクターの UI を使用すると、コレクターポッドのポート番号を設定できます。これは、データ収集サービスに影響を及ぼします。このウィンドウから、変更が発生するたびに USM の詳細を自動的に同期する再同期操作を有効にすることもできます。

データを収集するための組み込みコレクターの設定

組み込みコレクターがデータ収集を開始するのはいつですか。

デバイスライフサイクル管理および要素管理機能アプリケーションは、Crosswork Network Controller にオンボーディングされたデバイスに収集ジョブを割り当てます。これにより、重要なネットワーク情報とテレメトリデータの収集が容易になり、デバイス正常性レポートの正確性が確保され、他の指定されたタスクの実行が可能になります。

組み込みコレクターの設定ワークフロー

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

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

表 1. 組み込みコレクターの設定ワークフロー

タスク

次の手順を実行します。

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

組み込みコレクターアプリケーションの正常性のモニター

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

デバイス パッケージ

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

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

4. （オプション）カスタム収集ジョブを作成する。

収集ジョブの管理

データコレクターのグローバル設定

このセクションでは、組み込みコレクターに設定する必要があるグローバル設定の概要を示します。

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

外部の接続先にデータを送信する収集ジョブを設定するには、追加のライセンスが必要です。外部接続先を使用するように Crosswork を設定する前に、ライセンスをインストールすることをお勧めします。最初にライセンスをインストールしない場合でも、トライアルライセンスで 90 日間この機能を使用できます。期限が切れると、この機能は無効になります。

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

ライセンスステータスの表示

ライセンスのステータスを表示するには、次の手順を使用します。

  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）] になっている。

外部データ送信先の管理

Cisco Crosswork では、テレメトリデータをデポジットするために収集ジョブで使用される、Kafka や外部 gRPC などの外部データ送信先を作成できます。

データ送信先を管理するには、[管理（Administration）] > [Data Gatewayのグローバル設定（Data Gateway Global Settings）] > [データ送信先（Data Destinations）] に移動します。そこから、データ送信先を追加または変更したり、未使用の送信先を削除したり、設定されているすべての送信先を表示したりできます。


（注）  

Crosswork_Kafka と cd-astack-pipeline は内部データ送信先であり、更新または削除はできません。
図 2. [データ送信先（Data Destinations）] ウィンドウ
[データ送信先（Data Destinations）] ウィンドウ

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

データ送信先の詳細を表示するには、[データ送信先（Data Destinations）] ペインで、詳細を表示するデータ送信先の横にある アイコンをクリックします。詳細については、データ宛先の詳細の表示を参照してください。

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

始める前に

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

  • 外部 Kafka サーバーで次のプロパティが設定されている。


    （注）  

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

    • num.io.threads = 8

    • num.network.threads = 3

    • message.max.bytes= 30000000

  • データ収集に必要な Kafka トピックが、目的に応じて作成されている。

  • 新しい収集ジョブを開始する前に、Kafka 接続先に「reachability-topic」が設定されている。Kafka 接続先の正常性をモニターするために、この設定が必要です。

  • 複数のデータ送信先を追加することができます。

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

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

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

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

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

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

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

  • 組み込みコレクターでは、Kafka 接続先の接続先プロパティでカスタム値を設定できます（この手順のステップ 4 を参照）。


    （注）  

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

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

新しいデータ送信先を追加したりデータ送信先を変更するには、次の手順を実行します。組み込みコレクターは、収集したデータをこの送信先に送信します。

手順

ステップ 1

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

ステップ 2

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

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

（注）  

 

データ送信先を更新する場合、その送信先を使用しているコレクターは、その送信先との新しいセッションを確立する必要があります。データの収集は一時停止し、セッションが復元されると続行されます。

ステップ 3

外部データ接続先の要件に従って、次の値を入力または更新します。値が指定されていない場合は、デフォルトを開始点として使用することを検討してください。

フィールド 値 利用可能

gRPC

 利用可能

Kafka

接続先名（Destination Name）

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

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

対応

対応

サーバ タイプ（Server Type）

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

可。gRPC を選択

可。Kafka を選択

エンコーディング（Encoding）

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

対応

対応

圧縮タイプ（Compression Type）

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

Kafka は、snappy、gzip、lz4、zstd、および none をサポートします。zstd 圧縮タイプは、Kafka 2.0 以降でのみサポートされています。

gRPC は、snappy、gzip、および deflate をサポートしています。

対応

対応

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

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

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

  • 最小：1000000 バイト/1 MB

  • 最大：100000000 バイト/100 MB

非対応

対応

バッファメモリ（Buffer Memory）

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

  • デフォルト値：52428800 バイト/52.4288 MB

  • 最小：52428800 バイト/52.4288 MB

  • 最大：314572800 バイト/314.5728 MB

非対応

対応

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

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

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

  • 最小：16384 バイト/16.38 KB

  • 最大：314572800 バイト/314572.8 KB

非対応

対応

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

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

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

  • 最小：0 ms

  • 最大：5000 ms

非対応

対応

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

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

  • デフォルト値：30 秒

  • 最小：30 秒

  • 最大：60 秒

対応

対応

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

ステップ 4

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

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

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

    • カスタムバッファメモリ

    • カスタムバッチサイズ

      （注）  

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

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

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

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

  3. [+別を追加（+ 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 アドレスを追加できます。

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

対応

対応

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 UI にアップロードされた後に外部サーバーと組み込みコレクターを認証します。

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

（注）  

 

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

ステップ 9

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

次のタスク

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


重要

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

データ宛先の詳細の表示

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

宛先の表示ウィンドウ

データ送信先の削除

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

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

ステップ 1

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

ステップ 2

表示された送信先一覧から削除したいデータ送信先を 1 つまたは複数選択して、[Delete] アイコン ボタンをクリックします。

ステップ 3

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

デバイス パッケージ

デバイス管理により、デバイスパッケージを介して、組み込みコレクターのデータ収集機能がシスコのアプリケーションとサードパーティデバイスに拡張されます。組み込みコレクターは、システムおよびカスタムのデバイスパッケージをサポートします。

システムデバイスと MIB パッケージは、Crosswork ソフトウェアにバンドルされており、システムインスタンスに自動的にダウンロードされます。システムデバイスと MIB パッケージは変更できません。

カスタムデバイスパッケージは、デバイスの対象範囲と収集機能をサードパーティデバイスに拡張します。

デバイスパッケージへのアクセス方法

[管理（Administration）] > [データコレクターのグローバル設定（Data Collector(s) Global Settings）] から [パッケージ（Packages）] にアクセスします。[システムパッケージ（System packages）] または [カスタムパッケージ（Custom packages）] を選択します。

システムパッケージ

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

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


重要

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

システムパッケージをダウンロードするには、メインメニューから、[管理（Administration）] > [データコレクターのグローバル設定（Data Collector(s) Global Settings）] > [システムパッケージ（System Packages）] を選択します。[ファイル名（File Name）] 列のパッケージ名の横にある ダウンロード アイコン ボタンをクリックします。

カスタムパッケージ

次の 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 は複数のカスタム MIB パッケージをサポートしていません。


    （注）  

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

  3. SNMP デバイスパッケージ：組み込みコレクターでは、必要な MIB と YANG 記述を追加したカスタム SNMP デバイスパッケージをアップロードすることで、SNMP カバレッジを拡張できます。

  4. 集約パッケージ：集約パッケージを使用すると、サポートされている複数のファイル拡張子を 1 つのパッケージに含めることができます。Crosswork UI では、これらのパッケージをアップロードまたはダウンロードできます。各パッケージには、次の拡張子を持つ 1 つまたは複数のファイルを含めることができます。

    コレクターファイル

    • YANG（.yang）

    • MIB（.mib、.my）

    • 定義（.def）

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

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

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

    • Zips（.zip）

    • SDU バンドル（.sdu）

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

これは、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 パッケージの更新を取得します。
カスタムパッケージの削除

Cisco Crosswork からカスタムパッケージを削除すると、すべての YANG ファイルと XAR ファイルが自動的に削除されます。カスタムパッケージを削除すると、そのカスタムパッケージに依存するすべての収集タスクに影響します。

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

手順

ステップ 1

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

ステップ 2

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

ステップ 3

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

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

[グローバルパラメータ（Global Parameters）] ウィンドウでは、ネットワーク内のすべてのデータコレクターのポートを更新できます。


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

手順

ステップ 1

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

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

ステップ 2

次のパラメータの 1 つ以上を変更します。

（注）  

 
更新するポート値が有効なポートであり、既存のポート値と競合しないことを確認してください。デバイス上で同じポート値を設定する必要があります。

パラメータ名

説明

単一 VM 展開のデフォルト値
CLI セッションの数（Number of CLI sessions）

組み込みデータコレクターとデバイス間で設定できる CLI セッションの最大数。

（注）  

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

3

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

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

120

許容範囲は 1 ～ 120 秒です
SNMP Trap Port 展開環境および構成要件に応じて、この値を変更します。

31062

許容範囲は 30160 ～ 31560 です。
Syslog UDP ポート 展開環境および構成要件に応じて、この値を変更します。

30514

許容範囲は 30160 ～ 31560 です。
Syslog TCP ポート

-

30898

許容範囲は 30160 ～ 31560 です。
Syslog TLS ポート

-

30614

許容されるポートの範囲は 30160 ～ 31560 です。
SNMPv3 の詳細の再同期

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

このオプションを有効にすると、初回の収集が失敗した後、変更があるたびに USM の詳細が自動的に同期されます。デフォルトでは、このオプションはディセーブルです。

無効

ステップ 3

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

ステップ 4

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

ネットワーク内の組み込みデータコレクターでのパラメータの更新が成功したかどうかを示すウィンドウが表示されます。

  1. すべての組み込みデータコレクターが正常に更新された場合、更新が成功したことを示す成功メッセージが UI に表示されます。

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


    （注）  

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

収集ジョブの管理

アプリケーションは、収集ジョブを介してデータ収集を要求します。その後、Cisco Crosswork はこれらの収集ジョブを、要求を処理するコレクターに割り当てます。コレクターは、収集するデータのタイプに応じてデータ収集を開始します。

組み込みコレクターは、CLI、SNMP、gNMI（ダイヤルイン）、syslog などのプロトコルを使用してデータを収集できます。サポートされているプロトコルのいずれかを介して転送可能である限り、コレクターはどのようなタイプのデータでも収集できます。

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

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

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

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

収集したデータは、1 回の収集要求で外部のデータ送信先と Crosswork Network Controller に転送できます。

[収集ジョブ（Collection Jobs）] ページで、現在アクティブな収集ジョブを表示できます。

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

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

収集ジョブのタイプ

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

作成した収集ジョブごとに、組み込みコレクターは収集要求を実行し、収集したデータを指定されたデータ送信先に転送します。

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

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

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

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


（注）  

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

CLI 収集ジョブ

組み込みコレクターは、ネットワークデバイスからの CLI ベースのデータ収集をサポートしています。このタイプの収集ジョブでは、次のコマンドがサポートされています。

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

  • traceroute

  • dir

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

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

CLI 収集ジョブのサンプルペイロード

この例では、Crosswork は、デバイスで使用される UUID を含むデータを外部の Kafka 接続先に送信します。

  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 収集ジョブ

組み込みコレクターでは、デバイスでサポートされている OID に基づく SNMP ベースのデータ収集がサポートされます。SNMP OID ベースの収集ジョブは、Cisco Crosswork UI から、または API を使用して作成でき、SNMP トラップは API を使用して作成できます。

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


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

OID が解決されると、SNMP コレクターへの入力として提供されます。

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

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

  • ポーリングデータ

    • SNMP V2

    • SNMP V3（no auth nopriv、auth no priv、authpriv）

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

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

  • トラップ

    • SNMP V2

    • SNMP V3（no auth nopriv、auth no priv、authpriv）

デバイスでの設定例：

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

表 2. デバイスで 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 31062

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

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

（注）  

 

ここに記載されている IP アドレスは、組み込みコレクターの仮想 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 31062

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

（注）  

 

ここに記載されている IP アドレスは、組み込みコレクタの仮想 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 のホスト情報を構成します。

組み込みコレクターは、UDP ポート 31062 でトラップをリッスンします。


（注）  

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

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

SNMP トラップを受信すると、 次のように動作します。

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

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


    （注）  

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

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


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

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

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

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

表 3. サポートされている非 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"
    }
  ]
}

Syslog 収集ジョブ

組み込みコレクターは、デバイスからの syslog ベースのイベント収集をサポートしています。


重要

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

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

  • RFC5424 syslog 形式

  • RFC3164 syslog 形式


（注）  

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

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


（注）  

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

RFC3164 Syslog 形式の設定

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

IOS XR の場合： 

logging <CDG IP> port 30514 OR logging <CDG IP> vrf <vrfname> port 30514 
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 309898 session-id string <sessionidstring> --> To use TCP channel
OR
logging host <CDG IP> transport udp port 30514 session-id string <sessionidstring> ---> To use UDP channel
OR
logging host <CDG IP> vrf Mgmt-intf transport udp port 30514 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 30514 OR logging <server 1> vrf <vrfname> port 30514 
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 309898 session-id string <sessionidstring> --> To use TCP channel
OR
logging host <CDG IP> transport udp port 30514 session-id string <sessionidstring> ---> To use UDP channel
OR
logging host <CDG IP> vrf Mgmt-intf transport udp port 30514 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 の設定

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

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

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

Syslog 証明書のダウンロード

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

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

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

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

デバイスでの 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 Southbound IP>
!
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 30614
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に組み込みコレクターの 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 30614

gNMI 収集ジョブ

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


（注）  

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

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

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

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

組み込みコレクター は、gNMI の次のタイプのサブスクライブオプションをサポートしています。

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

タイプ

サブタイプ

説明

1 回

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

ストリーム

SAMPLE

パターンベースの収集。

ON_CHANGE

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

TARGET_DEFINED

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

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


（注）  

  • 組み込みコレクターは、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 間でのセキュア 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 証明書の設定

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


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

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

手順

ステップ 1

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

ステップ 2

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

ステップ 3

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

  • [デバイス証明書名（Device Certificate Name）]：証明書の名前を入力します。

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

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

ステップ 4

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

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

デバイスへの証明書のインポートとインストール

このセクションでは、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 ポートとして指定して、デバイスのセキュアプロトコルの詳細を更新します。

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

図 6. [デバイスの詳細の編集（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

[ジョブの詳細（Job details）] ページで、次のフィールドに値を入力します。

図 7. [ジョブの詳細（Job Details）] ウィンドウ
[ジョブの詳細（Job Details）] ウィンドウ

  • [アプリケーション ID（Application ID）]：アプリケーションの一意の識別子。

  • [コンテキスト（Context）]：すべての収集ジョブでアプリケーションのサブスクリプションを識別するための一意の識別子。

  • [コレクタータイプ（Collector Type）]：収集のタイプ（CLI または SNMP）を選択します。

[次へ（Next）] をクリックします。

ステップ 4

データを収集するデバイスを選択します。デバイスタグに基づいて選択することも、手動で選択することもできます。[次へ（Next）] をクリックします。

図 8. [デバイスの選択（Select Devices）] ウィンドウ
[デバイスの選択（Select Devices）] ウィンドウ

ステップ 5

（CLI での収集の場合にのみ適用）次のセンサーの詳細を入力します。

図 9. CLI パスの [センサーの詳細（Sensor Details）] ウィンドウ
[センサーの詳細（Sensor Details）] ウィンドウ

  • [データ送信先の選択（Select Data Destination）] ドロップダウンリストからデータ送信先を選択します。

  • 左側の [センサータイプ（Sensor Types）] ペインからセンサータイプを選択します。

[CLI パス（CLI PATH）] を選択した場合は、[追加（Add）] アイコン ボタンをクリックして、[CLI パスの追加（Add CLI Path）] ダイアログボックスに次のパラメータを入力します。

図 10. [CLIパスの追加（Add CLI Path）] ダイアログボックス
[CLIパスの追加（Add CLI Path）] ダイアログボックス

  • [収集パターン（Collection Cadence）]：プッシュまたはポーリングパターンを秒単位で指定します。

  • [コマンド（Command）]：CLI コマンド

  • [トピック（Topic）]：出力先に関連付けられているトピック。

    （注）  

     
    外部 gRPC サーバーを使用する場合、トピックは任意の文字列にできます。

[デバイスパッケージ（Device Package）] を選択した場合は、[追加（Add）] アイコン ボタンをクリックし、[デバイスパッケージセンサーの追加（Add Device Package Sensor）] ダイアログボックスに次のパラメータの値を入力します。

図 11. [デバイスパッケージセンサーの追加（Add Device Package Sensor）] ダイアログボックス
[デバイスパッケージセンサーの追加（Add Device Package Sensor）] ダイアログボックス

  • [収集パターン（Collection Cadence）]：プッシュまたはポーリングパターンを秒単位で指定します。

  • [デバイスパッケージ名（Device Package Name）]：デバイスパッケージの作成時に使用するカスタム XDE デバイスパッケージの ID。

  • [関数名（Function Name）]：カスタム XDE デバイスパッケージ内の関数名。

  • [トピック（Topic）]：出力先に関連付けられているトピック。

パラメータのキーと文字列の値を入力します。

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

ステップ 6

（SNMP での収集の場合にのみ適用）次のセンサーの詳細を入力します。

図 12. SNMP パスの [センサーの詳細（Sensor Details）] ウィンドウ
[センサーの詳細（Sensor Details）] ウィンドウ

  • [データ送信先の選択（Select Data Destination）] ドロップダウンリストからデータ送信先を選択します。

  • 左側の [センサータイプ（Sensor Types）] ペインからセンサータイプを選択します。

[SNMP MIB] を選択した場合は、[追加（Add）] アイコン ボタンをクリックして、[SNMP MIB の追加（Add SNMP MIB）] ダイアログボックスに次のパラメータを入力します。

図 13. [SNMP MIBの追加（Add SNMP MIB）] ダイアログボックス
[SNMP MIBの追加（Add SNMP MIB）] ダイアログボックス

  • [収集パターン（Collection Cadence）]：プッシュまたはポーリングパターンを秒単位で指定します。

  • OID

  • [操作（Operation）]：リストから操作を選択します。

  • [トピック（Topic）]：出力先に関連付けられているトピック。

[デバイスパッケージ（Device Package）] を選択した場合は、[追加（Add）] アイコン ボタンをクリックし、[デバイスパッケージセンサーの追加（Add Device Package Sensor）] ダイアログボックスに次のパラメータの値を入力します。

図 14. [デバイスパッケージセンサーの追加（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 ネットワークコントローラ に登録されているすべての組み込みコレクターインスタンスで現在アクティブな収集ジョブのステータスをモニターできます。

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

この左側のペインには、すべてのアクティブな収集ジョブが、ステータス、アプリ ID、コンテキスト ID、およびアクションとともに一覧表示されます。[アクション（Action）] ドロップダウンでは、次の操作が可能です。

  • [削除（Delete）]：収集ジョブを削除します。

  • [更新（Refresh）]：収集ジョブのステータスと、ジョブに関連付けられているタスクを更新します。

[ジョブの詳細（Job Details）] ペインには、左側ペインの特定のジョブに関連付けられているすべての収集タスクの詳細が表示されます。[収集ジョブ（Collection Jobs）] ペインの収集ジョブの全体的なステータスは、[ジョブの詳細（Jobs Details）] ペインのすべての収集タスクの集約ステータスです。

[収集ジョブ（Collection Jobs）] ペインでジョブを選択すると、[ジョブの詳細（Job Details）] ペインに次の詳細が表示されます。

  • 収集ジョブに関連付けられたアプリケーション名とコンテキスト。

  • 収集ジョブのステータス。


    （注）  

    • デバイスが組み込みコレクターに接続された後は、そのデバイスに関連付けられている収集タスクのステータスは、[不明（Unknown）] です。

    • 次のいずれかの理由で、ジョブのステータスが [不明（Unknown）] になる可能性があります。

      • 組み込みコレクターがまだそのステータスを報告していない。

      • 組み込みコレクターと Cisco Crosswork 間の接続が失われた。

      • 組み込みコレクターは収集ジョブを受信したが、実際の収集はまだ保留中になっている。たとえば、トラップが組み込みコレクターのサウスバウンド インターフェイスに送信されていない場合やデバイスがテレメトリ更新を送信していない場合などです。

      • 監視している SNMP トラップ収集ジョブのトラップ条件が発生していない。たとえば、リンクアップまたはリンクダウンの遷移を探していて、コレクターが確立されてからリンク状態が変更されていない場合、状態は [不明（Unknown）] として報告されます。したがって、トラップベースの収集が機能していることを検証するには、実際にトラップをトリガーする必要があります。

    • 収集ジョブが処理された後、処理が成功した場合はステータスが [成功（Successful）] に変わり、それ以外の場合は [失敗（Failed）] に変わります。

    • 収集ジョブが低下状態の場合、その原因の 1 つとして、デバイスへの静的ルートが組み込みコレクターから消去されていることが考えられます。

    • エラー状態にある宛先へのコレクションは停止しません。宛先の状態はバックグラウンドで識別されます。宛先がエラー状態の場合、エラーカウントがインクリメントされます。[ディストリビューション（Distribution）] ステータスに表示されるエラーメッセージをドリルダウンし、それぞれのコレクターログを調べて問題を特定して解決します。

    • Cisco Crosswork Health Insights：KPI ジョブは、拡張された組み込みコレクターインスタンスにマッピングされたデバイスでのみ有効にする必要があります。標準の組み込みコレクターインスタンスにマッピングされているデバイスで 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）

収集/配布のステータス。変更ベースで組み込みコレクターから報告されます。詳細については、[収集/配信ステータス（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）

デバイスセンサーペアの最後のステータス変更が組み込みコレクターから報告された日時。

（注）  

  • Create Failed エラーは、N 台のデバイスのうちの一部のデバイスの設定に失敗したことを示します。ただし、収集は正常に設定されたデバイスで行われます。Control Status API を使用して、このエラーの原因となっている 1 つ以上のデバイスを特定できます。

  • NSO エラーが原因で特定のデバイスでジョブの作成が失敗した場合は、NSO エラーを修正した後、デバイスの管理状態を手動で最初に [ダウン（Down）] にしてから [アップ（Up）] に変更する必要があります。ただし、これを行うと、デバイス上の収集がリセットされます。

（注）  

[作成/削除失敗（Create/Delete failed）] エラーが別の画面ポップアップに表示されます。エラーの詳細を表示するには、ジョブステータスの横にある をクリックします。

  • 同じペイロードで PUT 収集ジョブ API を使用してジョブを再作成することもできます。

イベントベースの収集ジョブの収集ステータス

  1. データの収集が成功すると、[収集ジョブ（Collection Jobs）] ペインで収集ジョブのステータスが [不明（Unknown）] から [成功（Success）] に変わります。

  2. デバイスが組み込みコレクターから切断されると、対応するすべての収集ジョブが削除され、[収集ジョブ（Collection Jobs）] ペインに収集ジョブのステータスが [成功（Success）] と表示されます。[ジョブの詳細（Job Details）] ペインに表示されるデバイスまたは収集タスクはありません。

  3. デバイスが組み込みコレクターに接続されると、Crosswork は、ステータスが [不明（Unknown）] に設定されている新しい収集ジョブを受信します。このステータスは、デバイスからイベントを受信した後に [成功（Success）] に変わります。

  4. すでに組み込みコレクターに接続されているデバイスでデバイス設定が誤って更新された場合、組み込みコレクターがジョブとイベントを受信しても、[ジョブの詳細（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）] をクリックします。

組み込みコレクターアプリケーションの正常性のモニター

[CW組み込みコレクターとオフロードコンポーネント（CW Embedded Collectors and Offload Components）] タイルには、組み込みコレクターの動作と正常性の概要が示されます。このページでは、Crosswork コンテナで実行されているポッドの正常性に関する情報を確認できます。組み込みコレクターアプリケーションの全体的な正常性は、個々のポッドサービスの正常性の影響を受けます。

図 15. [CW組み込みコレクターとオフロードコンポーネント（CW Embedded Collectors and Offload Components）] ペイン
[CW組み込みコレクターとオフロードコンポーネント（CW Embedded Collectors and Offload Components）] ペイン

コレクターの正常性ステータスを確認するには、Crosswork UI に移動します。

手順

ステップ 1

メインメニューから、[管理（Administration）]、[Crosswork Manager]、[CW組み込みコレクターとオフロードコンポーネント（CW Embedded Collector and Offload Component）] タイルの順に選択します。

ステップ 2

（オプション）[Showtechのオプション（Showtech Options）] ドロップダウンから、次の操作を実行できます。

  • [すべて要求（Request All）]：ログとメトリックの両方を収集します。ログを表示するには、 [Crosswork Manager] > [アプリケーション管理（Application Management）] > [Showtech要求（Showtech Requests）] に移動します。

  • [メトリックを要求（Request Metrics）]：メトリック情報を収集します。

  • [ログを要求（Request Metrics）]：ログ情報を収集します。

  • [Showtechジョブの表示（View Showtech Jobs）]：Showtech ジョブの進行状況を表示します。または、 [Crosswork Manager] > [アプリケーション管理（Application Management）] > [Showtech要求（Showtech Requests）] からジョブのステータスとその他の詳細を確認することもできます。

  • [ログレベルの変更（Change Log Level）]：組み込みコレクター内のさまざまなコンポーネントのログレベルを変更できます。例：コレクター（cli-collector）、インフラストラクチャサービス（oam-manager）。ログレベルの変更は、変更が行われているコレクターにのみ影響します。

ステップ 3

（オプション）[アプリケーション アクション（Application Actions）] ドロップダウンから、次の操作を実行できます。

  • [インストール（Install）]：以前のコレクターと同じ情報（プロファイル、ホスト名、管理インターフェイス）を使用して新しいコレクターをインストールします。

  • [アップグレード（Upgrade）]：コレクターのバージョンをアップグレードします。

  • [アクティブ化（Activate）]：コレクターをアクティブにします。

  • [アンインストール（Uninstall）]：コレクターアプリケーションを削除します。この操作の実行は、現在進行中の収集ジョブに影響します。

コレクターのポッドの正常性のモニタリング

[組み込みコレクターとオフロードコンポーネント（Embedded Collector and Offload Component）] ペインでは、コレクターまたはマイクロサービスをホストするポッドの正常性ステータスの詳細な概要を取得できます。過負荷を回避し、リソースの追加やコレクターの負荷の軽減などのプロアクティブな是正措置を適時に実行するために、ネットワーク内のコレクターポッドの正常性を定期的にモニターすることをお勧めします。

図 16. [マイクロサービス（Microservices）] タブ
[組み込みコレクターとオフロードコンポーネント（Embedded Collector and Offload Component）] > [マイクロサービス（Microservices）] タブ

ポッドの正常性ステータスを表示するには、Crosswork UI に移動します。

手順

ステップ 1

メインメニューから、[管理（ Administration）]、[Crosswork Manager]、CW[組み込みコレクターとオフロードコンポーネント（CW Embedded Collector and Offload Component）] の順に選択します。

ステップ 2

[CW組み込みコレクターとオフロードコンポーネント（CW Embedded Collectors and Offload Components）] ペインを展開し、[マイクロサービス（Microservices）] タブをクリックします。

ステップ 3

（オプション）[マイクロサービス（Microservices）] タブで、[名前（Name）] フィールドにコレクター名を入力して、コレクターポッドを特定します。

ステップ 4

（オプション）このページで、[アクション（Actions）] 列の下にある をクリックして、次のアクションを実行します。

  • [再起動（Restart）]：コレクターポッドを再起動します。ポッドを再起動すると、進行中の収集プロセスが中断されます。プロセスを再起動、開始、または停止する必要がある場合は、常に Cisco TAC チームに相談することを強くお勧めします。

  • [Showtech要求（Showtech Requests）]：対応するコレクターポッドに対して実行された showtech ジョブを表示します。ログを表示するには、 [Crosswork Manager] > [アプリケーション管理（Application Management）] > [Showtech要求（Showtech Requests）] に移動する必要があります。

  • [すべて要求（Request All）]：ポッドのログとメトリックの両方を収集します。ログを表示するには、 [Crosswork Manager] > [アプリケーション管理（Application Management）] > [Showtech要求（Showtech Requests）] に移動します。

  • [メトリックを要求（Request Metrics）]：ポッドのメトリックを収集します。

  • [ログを要求（Request Logs）]：ポッドのログを収集します。

コレクターのアラームとイベントの表示

組み込みコレクターは、データ収集を妨げる異常を検出すると、アラームを生成します。アラームをモニターすることで、データ収集に影響を与える潜在的なコレクターの問題を検出し、必要に応じて修復アクションを実行できます。

アラームを表示するには、Crosswork Network Controller の UI から、[管理（Administration）]、[Crosswork Manager]、[CW組み込みコレクターとオフロードコンポーネント（CW Embedded Collector and Offload Component）] の順に選択します。

[アラーム（Alarms）] タブには、すべてのコレクターアラートとイベントが統合されてリスト表示されます。[アラーム（Alarms）] サブタブと [イベント（Events）] サブタブを切り替えて、それぞれの詳細を表示できます。

図 17. [イベント（Events）] タブ
[イベント（Events）] タブ

列をフィルタリングするか、[アクティブなアラームのみ（Active Alarms Only）] スライダを変更するか、または [設定（Settings）] アイコン アイコンを使用して列を追加または削除することにより、アラームまたはイベントのリストをフィルタリングします。

組み込みコレクターのトラブルシューティング

トラブルシューティングセクションには、組み込みコレクターで発生する可能性のある問題と修正措置に関する情報が記載されています。

管理状態が DOWN から UP に自動的に変更する

単一 VM 展開では、デバイスは組み込みコレクターに自動的に接続され、管理状態が DOWN からUP に変更されます。

回避策：状態を DOWN に変更するには、[デバイスの編集（Edit Device）] ページで手動で変更します。デバイスの編集について詳細は、『Cisco Crosswork Network Controller 7.0 Device Lifecycle Management』の「Edit Devices」セクションを参照してください。