モデル駆動型テレメトリ
モデル駆動型テレメトリは、YANG モデル化されたデータをデータ コレクタにストリーミングするためのメカニズムを提供します。このモジュールでは、モデル駆動型テレメトリについて説明し、テレメトリ リモート プロシージャ コール(RPC)の例を示します。
モデル駆動型テレメトリの前提条件
-
テレメトリを使用する際に必要なデータを理解して定義するには、YANG に関する知識が必要です。
-
XML、XML 名前空間、および XML XPath の知識。
-
IETF テレメトリ仕様で定義されている標準および原則の知識。
-
urn:ietf:params:netconf:capability:notification:1.1 機能は、hello メッセージでリストする必要があります。この機能は、IETF テレメトリをサポートするデバイスでのみアドバタイズされます。
-
NETCONF-YANG がデバイス上で設定済みであり稼働している必要があります。
(注)
NETCONF を使用しない場合でも、テレメトリが機能するように NETCONF-YANG を設定する必要があります。NETCONF-YANG の設定の詳細については、「NETCONF プロトコル」モジュールを参照してください。
show platform software yang-management process コマンドを使用して、次のプロセスが実行中であることを確認します。 Device# show platform software yang-management process confd : Running nesd : Running syncfd : Running ncsshd : Running dmiauthd : Running nginx : Running ndbmand : Running pubd : Running gnmib : Running
(注)
プロセス pubd はモデル駆動型テレメトリ プロセスであり、これが実行していない場合にはモデル駆動型テレメトリは機能しません。
次の表に、各デバイス管理インターフェイス(DMI)プロセスの詳細を示します。
表 1. フィールドの説明 デバイス管理インターフェイスプロセス名
主要な役割
confd
コンフィギュレーション デーモン
nesd
ネットワーク要素シンクロナイザデーモン
syncfd
同期デーモン(実行状態と対応するモデル間の同期を維持)
ncsshd
NETCONF セキュアシェル(SSH)デーモン
dmiauthd
DMI 認証デーモン。
nginx
NGINX Web サーバ。RESTCONF の Web サーバとして機能します。
ndbmand
NETCONF データベースマネージャ
pubd
モデル駆動型テレメトリに使用されるパブリケーションマネージャおよびパブリッシャ
gnmib
GNMI プロトコルサーバ。
NETCONF 固有の前提条件
-
NETCONF とその使用方法に関する次の知識。
-
NETCONF セッションの確立。
-
hello および機能メッセージの送受信。
-
確立された NETCONF セッションによる YANG XML RPC の送受信詳細については、 『Configure NETCONF / YANG and Validate Example for Cisco IOS XE 16.x Platforms』を参照してください。
-
NETCONF の有効化と検証
NETCONF の機能を確認するには、有効なユーザ名とパスワードを使用してデバイスへの SSH 接続を作成し、デバイスの機能を含む hello メッセージを受信します。
Device:~ USER1$ ssh -s cisco1@172.16.167.175 -p 830 netconf
cisco1@172.16.167.175's password: cisco1
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:base:1.1</capability>
<capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
<capability>urn:ietf:params:netconf:capability:xpath:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
<capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability
.
.
.
</capabilities>
<session-id>2870</session-id></hello>]]>]]>
Use < ^C > to exit
hello メッセージに対して正常な応答を受信すると、NETCONF を使用する準備が整います。
RESTCONF 固有の前提条件
-
RESTCONF とその使用方法に関する次の知識(RESTCONF を使用してサブスクリプションを作成する場合)。
-
RESTCONF がデバイスで設定されている必要があります。
-
RESTCONF は、RESTCONF RFC 8040 に準拠した、正しい形式の Uniform Resource Identifier(URI)を送信する必要があります。
RESTCONF の有効化と検証
適切なクレデンシャルと次の URI を使用して、RESTCONF を検証します。
Operation: GET
Headers:
" Accept: application/yang-data.collection+json, application/yang-data+json, application/yang-data.errors+json
" Content-Type: application/yang-data+json
Returned Output (omitted for breverity):
{
"ietf-restconf:data": {
"ietf-yang-library:modules-state": {
"module": [
{
"name": "ATM-FORUM-TC-MIB",
"revision": "",
"schema": "https://10.85.116.28:443/restconf/tailf/modules/ATM-FORUM-TC-MIB",
"namespace": "urn:ietf:params:xml:ns:yang:smiv2:ATM-FORUM-TC-MIB"
},
{
"name": "ATM-MIB",
"revision": "1998-10-19",
"schema": "https://10.85.116.28:443/restconf/tailf/modules/ATM-MIB/1998-10-19",
"namespace": "urn:ietf:params:xml:ns:yang:smiv2:ATM-MIB"
},
{
"name": "ATM-TC-MIB",
"revision": "1998-10-19",
"schema": "https://10.85.116.28:443/restconf/tailf/
..
<snip>
..
}
すべてのデバイス機能で前述の応答を受信すると、RESTCONF が正常に検証されます。
gRPC固有の前提条件
-
キー値 Google Protocol Buffers(GPB)エンコーディングを理解する gRPC コレクタを設定します。
モデル駆動型テレメトリの制約事項
-
yang-push ストリームを使用している場合、選択における自動階層は、変更時サブスクリプション向けにサポートされません。つまり、リストを選択するときに、リストの子リストが自動的には含まれません。たとえば、サブスクライバでは、子リストごとにサブスクリプションを手動で作成する必要があります。
-
データアクセス許可のチェックはサポートされていません。サブスクライバによって要求されたすべてのデータが送信されます。
-
サブツリー フィルタはサポートされていません。サブツリー フィルタが指定された場合、サブスクリプションは無効としてマークされます。
-
サブスクリプション パラメータの中で複数の受信者を定義することはサポートされていません。最初の受信者の宛先だけが試行されます。他の定義済みの受信者は無視されます。
gRPC 固有の制限事項
-
デバイスと受信者間の Transport Layer Security ベース(TLS ベース)の認証はサポートされていません。
yang-push 固有の制限
-
サブスクリプションの Quality of Service(QoS)はサポートされていません。
モデル駆動型テレメトリについて
次のセクションでは、モデル駆動型テレメトリのさまざまな側面について説明します。
モデル駆動型テレメトリの概要
テレメトリは、自動の通信プロセスです。これにより、測定およびその他のデータがリモート ポイントまたはアクセス不能なポイントで収集され、モニタ用の受信装置に送信されます。モデル駆動型テレメトリは、YANG モデル化されたデータをデータ コレクタにストリーミングするためのメカニズムを提供します。
アプリケーションでは、NETCONF、RESTCONF、または gRPC ネットワーク管理インターフェイス(gNMI)の各プロトコルを介した標準ベースの YANG データ モデルを使用して、必要とする特定のデータ項目をサブスクライブできます。サブスクリプションは CLI を使用して作成することもできます(設定済みサブスクリプションの場合)。
構造化データは、サブスクリプション基準とデータ タイプに基づき、定義されたパターンでまたは変更時にパブリッシュされます。
テレメトリ ロール
テレメトリを使用するシステムでは、さまざまなロールが関与します。このドキュメントでは、次のテレメトリ ロールを使用します。
-
パブリッシャ:テレメトリ データを送信するネットワーク要素。
-
受信者:テレメトリデータを受信します。コレクタとも呼ばれます。
-
コントローラ:サブスクリプションを作成するがテレメトリ データを受信しないネットワーク要素。作成したサブスクリプションに関連付けられたテレメトリデータが受信者に送信されます。管理エージェントまたは管理エンティティとも呼ばれます。
-
サブスクライバ:サブスクリプションを作成するネットワーク要素。技術的には、受信者でもある必要はありませんが、このドキュメントではどちらも同じです。
サブスクリプションの概要
サブスクリプションは、テレメトリ ロール間の関連付けを作成する項目であり、ロール間で送信されるデータを定義します。
具体的には、サブスクリプションは、テレメトリデータの一部として要求される一連のデータを定義するために使用されます。たとえば、データがいつ必要か、データの書式設定の方法、また暗黙的でない場合は誰(どの受信者)がデータを受信するかを定義します。
サポートされているサブスクリプションの最大数はプラットフォームによって異なりますが、現在は 100 個のサブスクリプションがサポートされています。サブスクリプションは、設定済みか動的のいずれかにすることができ、トランスポート プロトコルの任意の組み合わせを使用できます。有効なすべての設定済みサブスクリプションをアクティブにするために同時に多数のサブスクリプションが動作している場合、サブスクリプションの数が多すぎると、アクティブなサブスクリプションを削除したときに、非アクティブであるが有効な設定済みサブスクリプションの 1 つが試行されます。定期的にトリガーされるサブスクリプション(デフォルトの最小値は 100 センチ秒)と、変更時にトリガーされるサブスクリプションがサポートされています。
サブスクリプションの設定では、NETCONF やその他のノースバウンド プログラマブル インターフェイス(RESTCONF、gNMI など)がサポートされています。
Cisco IOS XE システムのテレメトリでは、ダイナミック サブスクリプションと設定済みサブスクリプションの 2 種類のサブスクリプションが使用されます。
動的サブスクリプションは、パブリッシャに接続するクライアント(サブスクライバ)によって作成されるため、ダイヤルインと見なされます。設定済みサブスクリプションでは、パブリッシャは受信者への接続を開始し、その結果ダイヤルアウトと見なされます。
ダイヤルインおよびダイヤルアウトのモデル駆動型テレメトリ
モデル駆動型テレメトリには、ダイヤルインとダイヤルアウトの 2 種類があります。
ダイヤルイン(動的) |
ダイヤルアウト(静的または設定済み) |
---|---|
テレメトリの更新は、イニシエータまたはサブスクライバに送信されます。 |
テレメトリの更新は、指定された受信者またはコレクタに送信されます。 |
サブスクリプションの存続期間は、そのサブスクリプションを作成した接続(セッション)に結び付けられ、その存続期間中テレメトリの更新が送信されます。実行コンフィギュレーションでは変更は観察されません。 |
サブスクリプションは実行コンフィギュレーションの一部として作成されます。これは、コンフィギュレーションが削除されるまでデバイス設定として残ります。 |
ダイヤルイン サブスクリプションはリロード後に再起動する必要があります。これは、確立された接続またはセッションがステートフル スイッチオーバー時に kill されるためです。 |
ダイヤルアウト サブスクリプションはデバイス設定の一部として作成され、ステートフル スイッチオーバー後に自動的に受信者に再接続します。 |
サブスクリプション ID は、サブスクリプションの確立が成功したときに動的に生成されます。 |
サブスクリプション ID は固定であり、設定の一部としてデバイス上で設定されます。 |
データ ソースの仕様
サブスクリプション内のテレメトリ データのソースは、ストリームとフィルタを使用して指定されます。ここでのストリームとは、関連する一連のイベントを指します。RFC 5277 ではイベント ストリームを、いくつかの転送基準に一致する一連のイベント通知として定義しています。
通常は、ストリームからの一連のイベントはフィルタ処理されます。異なるストリーム タイプごとに異なるフィルタ タイプが使用されます。
Cisco IOS XE は、yang-push と yang-notif-native の 2 つのストリームをサポートしています。
更新の通知
サブスクリプションの一部として、データが必要になるタイミングを指定できます。ただし、これはストリームによって異なります。ストリーム内で変更が行われたとき、またはイベントが発生した後にのみデータを使用できるようにするストリームもあれば、変更発生時に、または定義済みの時間間隔でデータを使用できるようにするストリームもあります。
この「タイミング」指定の結果は、対象のテレメトリ データを送る一連の更新通知となります。データの送信方法は、パブリッシャと受信者間の接続に使用されるプロトコルによって異なります。
サブスクリプション識別子
サブスクリプションは 32 ビットの正の整数値で識別されます。設定済みサブスクリプションの ID はコントローラによって設定され、動的サブスクリプションの場合はパブリッシャによって設定されます。
コントローラは、パブリッシャで作成された動的サブスクリプションとの競合を避けるために、設定済みサブスクリプションに使用する値を 0 ~ 2147483647 の範囲に制限する必要があります。動的サブスクリプションの ID 空間はグローバルです。つまり、独立して作成された動的サブスクリプションのサブスクリプション ID は重複しません。
サブスクリプション管理
管理操作の任意の形式を使用して、設定済みサブスクリプションの作成、削除、および変更を行うことができます。これには、CLI とネットワーク プロトコルの両方の管理操作が含まれます。
すべてのサブスクリプション(設定済みと動的)は、show コマンド、およびネットワーク プロトコル管理操作を使用して表示できます。
次の表で、サポートされているストリームとエンコーディング、およびサポートされている組み合わせについて説明します。入力としてのストリームは出力としてのプロトコルから独立していることを意図していますが、すべての組み合わせがサポートされているわけではありません。
トランスポートプロトコル |
NETCONF |
gRPC |
gNMI |
|||
---|---|---|---|---|---|---|
ダイヤルイン |
ダイヤルアウト |
ダイヤルイン |
ダイヤルアウト |
ダイヤルイン |
ダイヤルアウト |
|
Stream |
||||||
yang-push |
対応 |
非対応 |
非対応 |
対応 |
対応 |
非対応 |
yang-notif-native |
対応 |
非対応 |
非対応 |
対応 |
非対応 |
非対応 |
Encodings |
XML |
非対応 |
非対応 |
キー値 Google Protocol Buffers(kvGPB) |
JSON_IETF |
なし |
テレメトリの RPC サポート
確立された NETCONF セッションで、YANG XML リモート プロシージャ コール(RPC)の送受信が行えます。
テレメトリには <establish-subscription> RPC と <delete-subscription> RPC がサポートされています。
<establish-subscription> RPC が送信されると、パブリッシャからの RPC 応答には <rpc-reply> メッセージと、結果ストリングを含む <subscription-result> 要素が含まれます。
次の表は、<rpc-reply> メッセージでの応答と、応答の理由を示しています。
結果文字列 |
RPC |
原因 |
---|---|---|
ok |
<establish-subscription> <delete-subscription> |
成功 |
error-no-such-subscription |
<delete-subscription> |
指定されたテンプレートは存在しません。 |
error-no-such-option |
<establish-subscription> |
要求されたサブスクリプションはサポートされていません。 |
error-insufficient-resources |
<establish-subscription> |
サブスクリプションは次の理由により作成できません。
|
error-other |
<establish-subscription> |
その他の何らかのエラーです。 |
サービス gNMI
gNMI 仕様は、ハイレベル RPC を含む gNMI という名前の単一のトップレベルサービスを識別します。次に、サブスクライブサービス RPC を含むサービス定義を示します。
service gNMI{
.
.
.
rpc Subscribe(stream SubscribeRequest)
returns (stream SubscribeResponse);
<subscribe RPC> は、動的サブスクリプションを要求するために管理エージェントによって使用されます。この RPC には一連のメッセージが含まれています。次のセクションでは、<subscribe RPC> でサポートされているメッセージについて説明します。
SubscribeRequest メッセージ
このメッセージは、指定されたパスのセットに対するターゲットからの更新を要求するためにクライアントによって送信されます。次に、メッセージの定義を示します。
message SubscribeRequest {
oneof request {
SubscriptionList subscribe = 1;
PollRequest poll = 3;
AliasList aliases = 4;
}
Repeated gNMI_ext.Extensions = 5;
}
![]() (注) |
request.subscribe のみがサポートされます。 |
SubscribeResponse メッセージ
message SubscribeResponse {
oneof response {
Notification update = 1;
Bool sync_response = 3;
Error error = 4 [deprecated=true];
}
}
![]() (注) |
通知の更新のみがサポートされます。 |
SubscriptionList メッセージ
message SubscriptionList {
Path prefix = 1;
repeated Subscription subscription = 2;
bool use_aliases = 3;
QOSMarking qos = 4;
enum Mode {
STREAM = 0;
ONCE = 1;
POLL = 2;
}
Mode mode = 5;
bool allow_aggregation = 6;
repeated ModelData use_models = 7;
Encoding encoding = 8; // only JSON_IETF supported in R16.12
Bool updates_only = 9;
}
![]() (注) |
Path prefix(明示的な要素名のみ)、Subscription subscription、Mode mode STREAM、および Encoding encoding IETF_JSON がサポートされています。 |
プレフィックスメッセージ
message Path {
repeated string element = 1; [ deprecated ]
string origin = 2;
repeated PathElem elem = 3;
optional string target = 4;
}
![]() (注) |
origin(サポートされる値は「」と「openconfig」)、elem(サポートされる要素名はプレフィックスなし)、および target がサポートされます。 |
サブスクリプションメッセージ
このメッセージは、クライアントによってサブスクライブされるデータのセットを一般的に説明しています。通知動作を制御するために使用されるパスと属性が含まれます。次に、サブスクリプションメッセージの定義を示します。
message Subscription {
Path path = 1;
SubscriptionMode mode = 2;
uint64 sample_interval = 3;
bool suppress_redundant = 4;
uint64 heartbeat_interval = 5;
}
![]() (注) |
Path path、SubscriptionMode mode、Uint64 sample_interval、および Uint64 heartbeat_interval(値が 0 に設定されている場合のみ)がサポートされます。 |
パスメッセージ
有効なサブスクリプションには、パスが入力されています。これは、サブスクリプションリストに関連付けられたプレフィックスに追加されると、完全修飾パスを構成します。次に、パスメッセージの定義を示します。
message Path {
repeated string element = 1; [ deprecated ]
string origin = 2;
repeated PathElem elem = 3;
optional string target = 4;
}
![]() (注) |
origin(サポートされる値は「」と「openconfig」)、elem(サポートされる要素名はプレフィックスなし)、および target がサポートされます。 |
SubscriptionMode メッセージ
このメッセージは、通知の更新をトリガーする方法をターゲットに通知します。次に、SubscriptionMode メッセージの定義を示します。
enum SubscriptionMode {
TARGET_DEFINED = 0;
ON_CHANGE = 1;
SAMPLE = 2;
}
![]() (注) |
SAMPLE のみがサポートされます。 |
通知メッセージ
このメッセージは、サブスクリプションターゲットからコレクタにテレメトリデータを配信します。次に、通知メッセージの定義を示します。
message Notification {
int64 timestamp = 1;
Path prefix = 2;
string alias = 3;
repeated Update update = 4;
repeated Path delete = 5;
bool atomic = 6;
}
![]() (注) |
タイムスタンプ、プレフィックス、および更新がサポートされます。 |
ダイナミックサブスクリプション管理
ここでは、動的サブスクリプションを作成および削除する方法について説明します。
NETCONF ダイヤルインの動的サブスクリプションの作成
動的サブスクリプションは、パブリッシャに接続し、その接続内部のメカニズム(通常はRPC)を使用してサブスクリプション作成のための呼び出しを行うサブスクライバによって作成されます。サブスクリプションの存続期間は、サブスクライバとパブリッシャ間の接続の存続期間に制限され、テレメトリ データはそのサブスクライバにのみ送信されます。これらのサブスクリプションは、パブリッシャまたはサブスクライバのいずれかが再起動された場合は存続しません。動的サブスクリプションの作成にはインバンドの <establish-subscription> RPC を使用できます。<establish-subscription> RPC は、IETF テレメトリのサブスクライバからネットワーク デバイスに送信されます。RPC では、stream、xpath-filter、および period の各フィールドが必須です。
NETCONF による動的サブスクリプションの作成および削除に使用する RPC は、イベント通知のカスタムサブスクリプション draft-ietf-netconf-subscribed-notifications-03 および YANG データストア プッシュ更新のサブスクライブ draft-ietf-netconf-yang-push-07 で定義されています。
定期的な動的サブスクリプション
次に、ダイヤルインの定期的なサブスクリプションの例を示します。
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<establish-subscription
xmlns="urn:ietf:params:xml:ns:yang:ietf-event-notifications"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<stream>yp:yang-push</stream>
<yp:xpath-filter>/mdt-oper:mdt-oper-data/mdt-subscriptions</yp:xpath-filter>
<yp:period>1000</yp:period>
</establish-subscription>
</rpc>
変更時動的サブスクリプション
<establish-subscription xmlns="urn:ietf:params:xml:ns:yang:ietf-event-notifications"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<stream>yp:yang-push</stream>
<yp:xpath-filter>/cdp-ios-xe-oper:cdp-neighbor-details/cdp-neighbor-detail</yp:xpath-filter>
<yp:dampening-period>0</yp:dampening-period>
</establish-subscription>
動的サブスクリプションの削除
動的サブスクリプションを削除するには、インバンドの <delete subscription> RPC、 clear telemetry ietf subscription コマンド、<kill-subscription> RPC を使用し、トランスポートセッションを切断します。
gNMI では、SubscribeRequest.subscribe.subscription の各サブスクリプションが個別のダイナミック サブスクリプション ID として生成されます。<kill-subscription> RPC または CLI のクリアを使用してこれらのサブスクリプション ID のいずれかを強制終了すると、サブスクライブ要求で指定されたすべてのサブスクリプションが強制終了されます。
Cisco IOS XE Gibraltar 16.10.1 で導入された <delete-subscription> RPC は、サブスクライバのみが発行でき、そのサブスクライバが所有するサブスクリプションのみを削除します。
Cisco IOS XE Gibraltar 16.11.1 以降のリリースでは、clear telemetry ietf subscription コマンドを使用してダイナミックサブスクリプションを削除できます。Cisco IOS XE Gibraltar 16.11.1 で導入された <kill-subscription> RPC は、clear telemetry ietf subscription コマンドと同じ方法でダイナミック サブスクリプションを削除します。
親の NETCONF セッションが切断されると、サブスクリプションも削除されます。ネットワーク接続が中断された場合は、 SSH または NETCONF セッションがタイムアウトしてその後にサブスクリプションが削除されるまで、多少の時間がかかることがあります。
<kill-subscription> RPC は <delete-subscription> RPC と類似しています。ただし、<kill-subscription> RPC は、subscription-id 要素の代わりに、削除するサブスクリプションの ID を含む identifier 要素を使用します。ターゲット サブスクリプションで使用されるトランスポート セッションも、<delete-subscription> RPC で使用されているものと異なります。
CLI を使用したサブスクリプションの削除
Device# show telemetry ietf subscription all
Telemetry subscription brief
ID Type State Filter type
--------------------------------------------------------
2147483648 Dynamic Valid xpath
2147483649 Dynamic Valid xpath
Device# clear telemetry ietf subscription 2147483648
NETCONF <delete-Subscription> RPC を使用したサブスクリプションの削除
次に、NETCONF を使用してサブスクリプションを削除する例を示します。
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<delete-subscription xmlns="urn:ietf:params:xml:ns:yang:ietf-event-notifications"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<subscription-id>2147483650</subscription-id>
</delete-subscription>
</rpc>
NETCONF <kill-Subscription> RPC を使用したサブスクリプションの削除
<get>
<filter>
<mdt-oper-data xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-mdt-oper">
<mdt-subscriptions/>
</mdt-oper-data>
</filter>
</get>
* Enter a NETCONF operation, end with an empty line
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
<data>
<mdt-oper-data xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-mdt-oper">
<mdt-subscriptions>
<subscription-id>2147483652</subscription-id>
<base>
…
</base>
<type>sub-type-dynamic</type>
<state>sub-state-valid</state>
<comments/>
<mdt-receivers>
…
</mdt-receivers>
<last-state-change-time>2018-12-13T21:16:48.848241+00:00</last-state-change-time>
</mdt-subscriptions>
<mdt-subscriptions>
<subscription-id>2147483653</subscription-id>
<base>
…
</base>
<type>sub-type-dynamic</type>
<state>sub-state-valid</state>
<comments/>
<mdt-receivers>
…
</mdt-receivers>
<last-state-change-time>2018-12-13T21:16:51.319279+00:00</last-state-change-time>
</mdt-subscriptions>
<mdt-subscriptions>
<subscription-id>2147483654</subscription-id>
<base>
…
</base>
<type>sub-type-dynamic</type>
<state>sub-state-valid</state>
<comments/>
<mdt-receivers>
…
</mdt-receivers>
<last-state-change-time>2018-12-13T21:16:55.302809+00:00</last-state-change-time>
</mdt-subscriptions>
<mdt-subscriptions>
<subscription-id>2147483655</subscription-id>
<base>
…
</base>
<type>sub-type-dynamic</type>
<state>sub-state-valid</state>
<comments/>
<mdt-receivers>
…
</mdt-receivers>
<last-state-change-time>2018-12-13T21:16:57.440936+00:00</last-state-change-time>
</mdt-subscriptions>
</mdt-oper-data>
</data>
</rpc-reply>
<kill-subscription xmlns="urn:ietf:params:xml:ns:yang:ietf-event-notifications"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<identifier>2147483653</identifier>
</kill-subscription>
* Enter a NETCONF operation, end with an empty line
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
<subscription-result xmlns="urn:ietf:params:xml:ns:yang:ietf-event-notifications"
xmlns:notif-bis="urn:ietf:params:xml:ns:yang:ietf-event-notifications">notif-bis:ok</subscription-result>
</rpc-reply>
<get>
<filter>
<mdt-oper-data xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-mdt-oper">
<mdt-subscriptions/>
</mdt-oper-data>
</filter>
</get>
* Enter a NETCONF operation, end with an empty line
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
<data>
<mdt-oper-data xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-mdt-oper">
<mdt-subscriptions>
<subscription-id>2147483652</subscription-id>
<base>
…
</base>
<type>sub-type-dynamic</type>
<state>sub-state-valid</state>
<comments/>
<mdt-receivers>
…
</mdt-receivers>
<last-state-change-time>2018-12-13T21:16:48.848241+00:00</last-state-change-time>
</mdt-subscriptions>
<mdt-subscriptions>
<subscription-id>2147483654</subscription-id>
<base>
…
</base>
<type>sub-type-dynamic</type>
<state>sub-state-valid</state>
<comments/>
<mdt-receivers>
…
</mdt-receivers>
<last-state-change-time>2018-12-13T21:16:55.302809+00:00</last-state-change-time>
</mdt-subscriptions>
<mdt-subscriptions>
<subscription-id>2147483655</subscription-id>
<base>
…
</base>
<type>sub-type-dynamic</type>
<state>sub-state-valid</state>
<comments/>
<mdt-receivers>
…
</mdt-receivers>
<last-state-change-time>2018-12-13T21:16:57.440936+00:00</last-state-change-time>
</mdt-subscriptions>
</mdt-oper-data>
</data>
</rpc-reply>
設定済みサブスクリプションの管理
ここでは、設定済みサブスクリプションを作成、変更、および削除する方法について説明します。
設定済みサブスクリプションの作成
設定済みサブスクリプションは、コントローラによるパブリッシャでの管理操作によって作成され、サブスクリプションによって定義されたテレメトリデータの受信者の指定が明示的に含まれています。これらのサブスクリプションは、パブリッシャの再起動後も持続します。
設定済みサブスクリプションは複数の受信者を使用して設定できますが、最初の有効な受信者のみが使用されます。受信者がすでに接続されている場合、または接続中の場合は、他の受信者への接続は試行されません。その受信者が削除されると、別の受信者が接続されます。
設定済みダイヤルアウト サブスクリプションは、次の方法でデバイスに設定されます。
-
設定 CLI を使用し、コンソール/VTY を介してデバイス設定に変更を加えます。
-
NETCONF/RESTCONF を使用し、目的のサブスクリプションを設定します。
定期的なサブスクリプション
ここでは、設定済みサブスクリプションを作成するための RPC の例を示します。
次の例は、CLI を使用して、設定済みサブスクリプションのトランスポート プロトコルとして gRPC を設定する方法を示しています。
telemetry ietf subscription 101
encoding encode-kvgpb
filter xpath /memory-ios-xe-oper:memory-statistics/memory-statistic
stream yang-push
update-policy periodic 6000
source-vrf Mgmt-intf
receiver ip address 10.28.35.45 57555 protocol grpc-tcp
次の RPC の例は、NETCONF を使用して定期的なサブスクリプションを作成し、60 秒ごとにテレメトリの更新を受信者に送信する方法を示します。
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><edit-config>
<target>
<running/>
</target>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<mdt-config-data xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-mdt-cfg">
<mdt-subscription>
<subscription-id>200</subscription-id>
<base>
<stream>yang-push</stream>
<encoding>encode-kvgpb</encoding>
<period>6000</period>
<xpath>/memory-ios-xe-oper:memory-statistics/memory-statistic</xpath>
</base>
<mdt-receivers>
<address>10.22.23.48</address>
<port>57555</port>
<protocol>grpc-tcp</protocol>
</mdt-receivers>
</mdt-subscription>
</mdt-config-data>
</config>
</edit-config>
</rpc>
次に、RESTCONF を使用して定期的なサブスクリプションを作成する RPC の例を示します。
URI:https://10.85.116.28:443/restconf/data/Cisco-IOS-XE-mdt-cfg:mdt-config-data
Headers:
application/yang-data.collection+json, application/yang-data+json, application/yang-data.errors+json
Content-Type:
application/yang-data+json
BODY:
{
"mdt-config-data": {
"mdt-subscription":[
{
"subscription-id": "102",
"base": {
"stream": "yang-push",
"encoding": "encode-kvgpb",
"period": "6000",
"xpath": "/memory-ios-xe-oper:memory-statistics/memory-statistic"
}
"mdt-receivers": {
"address": "10.22.23.48"
"port": "57555"
}
}
]
}
}
変更時サブスクリプション
次の RPC の例は、NETCONF を使用して変更時サブスクリプションを作成し、ターゲットデータベースに変更が生じた場合にのみ更新を送信する方法を示します。
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><edit-config>
<target>
<running/>
</target>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<mdt-config-data xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-mdt-cfg">
<mdt-subscription>
<subscription-id>200</subscription-id>
<base>
<stream>yang-push</stream>
<encoding>encode-kvgpb</encoding>
<no-synch-on-start>false</no-synch-on-start>
<xpath>/cdp-ios-xe-oper:cdp-neighbor-details/cdp-neighbor-detail</xpath>
</base>
<mdt-receivers>
<address>10.22.23.48</address>
<port>57555</port>
<protocol>grpc-tcp</protocol>
</mdt-receivers>
</mdt-subscription>
</mdt-config-data>
</config>
</edit-config>
</rpc>
次の RPC の例は、RESTCONF を使用して変更時サブスクリプションを作成する方法を示します。
URI:
https://10.85.116.28:443/restconf/data/Cisco-IOS-XE-mdt-cfg:mdt-config-data
Headers:
application/yang-data.collection+json, application/yang-data+json, application/yang-data.errors+json
Content-Type:
application/yang-data+json
BODY:
{
"mdt-config-data": {
"mdt-subscription":[
{
"subscription-id": "102",
"base": {
"stream": "yang-push",
"encoding": "encode-kvgpb",
"dampening period": "0",
"xpath": "/cdp-ios-xe-oper:cdp-neighbor-details/cdp
-neighbor-detail "
}
"mdt-receivers": {
"address": "10.22.23.48"
"port": "57555"
}
}
]
}
}
gNMI ダイヤルイン サブスクリプション
次に、gNMI ダイヤルイン サブスクリプションの例を示します。
subscribe: <
prefix: <>
subscription: <
path: <
origin: "openconfig"
elem: <name: "routing-policy">
>
mode: SAMPLE
sample_interval: 10000000000
>
mode: STREAM
encoding: JSON_IETF
>'
subscribe: <
prefix: <>
subscription: <
path: <
origin: "legacy"
elem: <name: "oc-platform:components">
elem: <
name: "component"
key: <
key: "name"
value: "PowerSupply8/A"
>
>
elem: <name: "power-supply">
elem: <name: "state">
>
mode: SAMPLE
sample_interval: 10000000000
>
mode: STREAM
encoding: JSON_IETF
>'
設定済みサブスクリプションの変更
設定済みサブスクリプションを変更するには、次の 2 つの方法があります。
-
NETCONF <edit-config> RPC などの管理プロトコル設定操作
-
CLI(サブスクリプションの作成と同じ手順)
サブスクリプションの受信者はアドレスとポート番号によって識別されます。受信者を変更することはできません。受信者の特性(プロトコル、プロファイルなど)を変更するには、先に受診者を削除してから新しい受信者を作成する必要があります。
有効なサブスクリプションの有効な受信者設定が切断状態にあり、管理側で受信者への接続のセットアップ時に新しい試行を強制する場合は、同一の特性を持つ受信者を書き換える必要があります。
設定済みサブスクリプションの削除
CLI または管理操作を使用して、設定済みサブスクリプションを削除できます。no telemetry ietf subscription コマンドは、設定済みサブスクリプションを削除します。設定されたサブスクリプションは、設定インターフェイスからのみ削除できます。
CLI を使用したサブスクリプションの削除
Device# configure terminal
Device(config)# no telemetry ietf subscription 101
Device(config)# end
NETCONF を使用したサブスクリプションの削除
次の RPC の例は、設定済みサブスクリプションを削除する方法を示しています。
<edit-config>
<target>
<running/>
</target>
<config>
<mdt-config-data xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-mdt-cfg">
<mdt-subscription operation="delete">
<subscription-id>102</subscription-id>
</mdt-subscription>
</mdt-config-data>
</config>
</edit-config>
サブスクリプションのモニタリング
CLI および管理プロトコル操作を使用して、すべてのタイプのサブスクリプションを監視できます。
CLI
Device# show telemetry ietf subscription 2147483667 detail
Telemetry subscription detail:
Subscription ID: 2147483667
State: Valid
Stream: yang-push
Encoding: encode-xml
Filter:
Filter type: xpath
XPath: /mdt-oper:mdt-oper-data/mdt-subscriptions
Update policy:
Update Trigger: periodic
Period: 1000
Notes:
NETCONF
次に、テレメトリのサブスクリプションに関する情報を表示する NETCONF メッセージの例を示します。
<get>
<filter>
<mdt-oper-data xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-mdt-oper">
<mdt-subscriptions/>
</mdt-oper-data>
</filter>
</get>
* Enter a NETCONF operation, end with an empty line
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
<data>
<mdt-oper-data xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-mdt-oper">
<mdt-subscriptions>
<subscription-id>101</subscription-id>
<base>
<stream>yang-push</stream>
<encoding>encode-kvgpb</encoding>
<source-vrf>RED</source-vrf>
<period>10000</period>
<xpath>/ios:native/interface/Loopback[name="1"]</xpath>
</base>
<type>sub-type-static</type>
<state>sub-state-valid</state>
<comments/>
<mdt-receivers>
<address>5.22.22.45</address>
<port>57500</port>
<protocol>grpc-tcp</protocol>
<state>rcvr-state-connecting</state>
<comments/>
<profile/>
<last-state-change-time>1970-01-01T00:00:00+00:00</last-state-change-time>
</mdt-receivers>
<last-state-change-time>1970-01-01T00:00:00+00:00</last-state-change-time>
</mdt-subscriptions>
<mdt-subscriptions>
<subscription-id>2147483648</subscription-id>
<base>
<stream>yang-push</stream>
<encoding>encode-xml</encoding>
<source-vrf/>
<period>1000</period>
<xpath>/if:interfaces-state/interface[name="GigabitEthernet0/0"]/oper-status</xpath>
</base>
<type>sub-type-dynamic</type>
<state>sub-state-valid</state>
<comments/>
<mdt-receivers>
<address>5.22.22.45</address>
<port>51259</port>
<protocol>netconf</protocol>
<state>rcvr-state-connected</state>
<comments/>
<profile/>
<last-state-change-time>1970-01-01T00:00:00+00:00</last-state-change-time>
</mdt-receivers>
<last-state-change-time>1970-01-01T00:00:00+00:00</last-state-change-time>
</mdt-subscriptions>
</mdt-oper-data>
</data>
</rpc-reply>
ストリーム
ストリームは、サブスクライブ可能な一連のイベントを定義します。ほぼすべてのイベントがこの一連のイベントとして有効です。ただし、各ストリームの定義に従い、すべてのイベントの候補は何らかの形で関連しています。ここでは、サポートされているストリームについて説明します。
サポートされているストリームのセットを表示するには、管理プロトコル操作を使用して、mdt-streams コンテナにある Cisco-IOS-XE-mdt-oper モジュール(YANG モデル Cisco-IOS-XE-mdt-oper.yang からのもの)から streams テーブルを取得します。
次に、NETCONF を使用して、サポートされているストリームを取得する例を示します。
<get>
<filter>
<mdt-oper-data xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-mdt-oper">
<mdt-streams/>
</mdt-oper-data>
</filter>
</get>
* Enter a NETCONF operation, end with an empty line
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
<data>
<mdt-oper-data xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-mdt-oper">
<mdt-streams>
<stream>native</stream>
<stream>yang-notif-native</stream>
<stream>yang-push</stream>
</mdt-streams>
</mdt-oper-data>
</data>
</rpc-reply>
この例は、native、yang-notif-native、yang-push の 3 つのストリームがサポートされていることを示しています。ストリーム native は汎用としては使用できず、無視できます。
![]() (注) |
現在のところ、サポートされているストリームのリストを返す CLI はありません。 |
YANG-push ストリーム
yang-push ストリームは、サポートされている YANG モデルにより記述される、構成データベース内と運用データベース内のデータです。このストリームは、ストリームの中で対象とするデータを指定するための XPath フィルタをサポートしており、XPath 式は対象のデータを定義する YANG モデルに基づきます。
このストリームの更新通知は、対象のサブスクリプションについて、データの変更時または固定間隔で送信される場合がありますが、両方に対応して送信されることはありません。現在存在しないデータのサブスクリプションは許可され、通常のサブスクリプションとして実行されます。
サポートされている唯一のターゲットデータベースは「実行中」です。
変更時機能の決定
現在のところ、変更時サブスクリプションを使用し、サブスクライブ可能なデータのタイプについて YANG モデルの中で指定する手段はありません。変更時サブスクリプションを使用して、サブスクライブができないデータにサブスクライブしようとすると、失敗(動的)となるか、無効なサブスクリプション(設定済み)となります。On-Change パブリケーションの詳細については、「On-Change Publication for yang-push」の項を参照してください。
IETF ドラフトへの準拠
yang-push ストリームを使用するテレメトリは、テレメトリの IETF NETCONF ワーキング グループの初期ドラフトに基づいています。これらを次に示します。
![]() (注) |
対応するドラフトに記載されている次の機能はサポートされていません。 |
-
サブツリー フィルタ
-
アウトオブバンドの通知
-
サポート対象として明示的に記載されていないすべてのサブスクリプション パラメータ
YANG-push の XPath フィルタ
サブスクライブ先の yang-push ストリーム内のデータセットは、XPath フィルタを使用して指定する必要があります。XPath 式には次のガイドラインが適用されます。
-
XPath 式では、リストまたはコンテナに 1 つのエントリを指定するためのキーを持たせることができます。サポートされているキー指定の構文は次のとおりです。 [{key name}={key value}]
XPath 式の例を次に示します。 filter xpath /rt:routing-state/routing-instance[name="default"]/ribs/rib[name="ipv4-default"]/routes/route # VALID!
複合キーを使用するには、複数のキー指定を使用します。キーの名前と値は正確である必要があります。範囲やワイルドカードによる値はサポートされていません。
-
XPath 式で、キーの間に [] を使用して複数のキーを選択し、”. で文字列をカプセル化します。XPath 式の例を次に示します。 filter xpath /environment-ios-xe-oper:environment-sensors/environment-sensor[location=\"Switch\ 1\"] [name=\"Inlet\ Temp\ Sens\"]/current-reading
-
XPath 式では、単一のサブスクリプションで複数のオブジェクトをサポートできるように、結合演算子(|)を使用できます。ユニオン演算子は NETCONF トランスポートでのみ機能し、gRPC では機能しません。
YANG-push の定期パブリケーション
定期的なサブスクリプションでは、サブスクライブ対象情報による最初のプッシュ更新は即時に送信されます。ただしデバイスがビジー状態であったりネットワークが混雑していたりすると遅延することがあります。次に更新は、設定された定期タイマーの満了時に送信されます。たとえば、期間を 10 分と設定すると、サブスクリプションの作成直後に最初の更新が送信され、その後は 10 分おきに送信されます。
期間は、定期的なプッシュ更新間のセンチ秒(1/100 秒)単位の時間です。期間が 1000 であれば、サブスクライブ対象情報の更新は 10 秒ごとになります。設定できる最小の期間間隔は 100(つまり 1 秒)です。デフォルト値はありません。この値は、動的サブスクリプションの場合は <establish‑subscription> RPC で明示的に設定する必要があり、設定済みサブスクリプションの場合は設定で明示的に設定する必要があります。
定期的な更新には、サポートされているすべてのトランスポート プロトコルに関連するサブスクライブ対象のデータ要素またはテーブルのフルコピーが含まれています。
定期的なサブスクリプションを使用して空のデータをサブスクライブすると、要求された期間で空の更新通知が送信されます。データが存在するようになると、次の期間の値が通常の更新通知として送信されます。
YANG-push の変更時パブリケーション
変更時サブスクリプションを作成する場合は、ダンプニング期間がないことを示すためにダンプニング期間を 0 に設定する必要があります。その他の値はサポートされていません。
変更時サブスクリプションでは、最初のプッシュ更新は、サブスクライブされたデータのセット全体です(IETF の文書で定義されている初期同期)。これは制御できません。以降の更新は、データが変更され、変更後のデータのみで構成されている場合に送信されます。ただし、変更とみなされる最小のデータ分解能は行です。したがって、変更時サブスクリプションが行内のリーフに対するものである場合、その行のいずれかの項目が変更されると、更新通知が送信されます。更新通知の正確な内容はトランスポート プロトコルによって異なります。
また、変更時サブスクリプションは階層状ではありません。つまり、子コンテナを持つコンテナにサブスクライブしても、子コンテナ内の変更はサブスクリプションには認識されません。
現在存在しないデータのサブスクリプションは許可され、通常のサブスクリプションとして実行されます。初期同期更新通知は空であり、データが利用可能になるまでそれ以上更新されません。
XPath 式は単一のオブジェクトを指定する必要があります。このオブジェクトには、コンテナ、リーフ、リーフリスト、またはリストを使用できます。
yang-notif-native ストリーム
yang-notif-native ストリームは、パブリッシャ内の任意の YANG 通知であり、通知の元のイベントソースで Cisco IOS XE のネイティブのテクノロジーが使用されています。このストリームは、対象となる通知を指定する XPath フィルタもサポートしています。このストリームの更新通知は、通知の対象になるイベントが発生した場合にのみ送信されます。
このストリームは変更時サブスクリプションのみをサポートしているため、ダンプニング間隔として値 0 を指定する必要があります。
yang-notif-native の XPath フィルタ
サブスクライブ先の yang-notif-native ストリーム内のデータセットは、XPath フィルタを使用して指定します。次のガイドラインが XPath 式に適用されます。
-
XPath 式は YANG 通知全体を指定する必要があります。属性のフィルタ処理はサポートされていません。
-
ユニオン演算子 (|) はサポートされていません。
Cisco Catalyst 9800 ワイヤレスコントローラの XPath 値と対応するレート
Cisco-IOS-XE-wireless-mesh-rpc の XPath /exec-linktest-ap/data-rate-idx
で許容されている値と対応するレートを次に示します。
ewlc-mesh-linktest-rate-idx-1 1 Mbps
ewlc-mesh-linktest-rate-idx-2 2 Mbps
ewlc-mesh-linktest-rate-idx-3 5 Mbps
ewlc-mesh-linktest-rate-idx-4 6 Mbps
ewlc-mesh-linktest-rate-idx-5 9 Mbps
ewlc-mesh-linktest-rate-idx-6 11 Mbps
ewlc-mesh-linktest-rate-idx-7 12 Mbps
ewlc-mesh-linktest-rate-idx-8 18 Mbps
ewlc-mesh-linktest-rate-idx-9 24 Mbps
ewlc-mesh-linktest-rate-idx-10 36 Mbps
ewlc-mesh-linktest-rate-idx-11 48 Mbps
ewlc-mesh-linktest-rate-idx-12 54 Mbps
ewlc-mesh-linktest-rate-idx-13 108 Mbps
ewlc-mesh-linktest-rate-idx-14 m0
ewlc-mesh-linktest-rate-idx-15 m1
ewlc-mesh-linktest-rate-idx-16 m2
ewlc-mesh-linktest-rate-idx-17 m3
ewlc-mesh-linktest-rate-idx-18 m4
ewlc-mesh-linktest-rate-idx-19 m5
ewlc-mesh-linktest-rate-idx-20 m6
ewlc-mesh-linktest-rate-idx-21 m7
ewlc-mesh-linktest-rate-idx-22 m8
ewlc-mesh-linktest-rate-idx-23 m9
ewlc-mesh-linktest-rate-idx-24 m10
ewlc-mesh-linktest-rate-idx-25 m11
ewlc-mesh-linktest-rate-idx-26 m12
ewlc-mesh-linktest-rate-idx-27 m13
ewlc-mesh-linktest-rate-idx-28 m14
ewlc-mesh-linktest-rate-idx-295 m15
TLDP 変更時の通知
Targeted Label Discovery Protocol(T-LDP)は、直接接続されていないラベルスイッチドルータ(LSR)間の LDP セッションです。TLDP 変更時の通知機能は、TLDP セッションが起動または停止したとき、および TLDP が設定またはディセーブルになったときにユーザに通知します。通知を機能させるには、TLDP を有効にする必要があります。
イベントベースの通知は、次の 2 つのシナリオで生成されます。
-
設定されたイベントは、TLDP が設定され、デバイスから削除されたときに生成されます。通知は、TLDP セッションがアップまたはダウンしたときにも生成されます。
-
通知は、TLDP セッションがアップまたはダウンしたときにも生成されます。
トランスポート プロトコル
データの送信方法は、パブリッシャと受信者間の接続に使用されるプロトコルによって決まります。このプロトコルはトランスポート プロトコルと呼ばれ、設定済みサブスクリプションの管理プロトコルからは独立しています。トランスポートプロトコルは、データのエンコーディング(XML、Google Protocol Buffers(GPB)など)と更新通知自体の形式に影響を与えます。
![]() (注) |
また、選択したストリームも更新通知の形式に影響を与える場合があります。 |
サポートされているトランスポートプロトコルは、gNMI、gRPC、NETCONF です。
NETCONF プロトコル
NETCONF プロトコルは、動的サブスクリプションのトランスポートにのみ使用でき、yang-push ストリームと yang-notif-native ストリームで使用できます。
NETCONF をトランスポート プロトコルとして使用する場合は、次の 3 つの更新通知形式が使用されます。
-
サブスクリプションで yang-push ストリームが使用されていて、定期的な場合、または、初期同期更新通知が変更時サブスクリプションで送信される場合。
-
サブスクリプションで yang-push ストリームが使用されていて、初期同期更新通知以外の変更時サブスクリプションの場合。
-
サブスクリプションで yang-notif-native ストリームが使用されている場合。
yang-push 形式
yangpush ソースストリームが NETCONF を介して XML エンコーディングのトランスポートとして送信される場合、2 つの更新通知形式が定義されます。これらの更新通知形式は、draft-ietf-netconf-yang-push-07 に基づいています。詳細については、IETF ドラフトの 3.7 項を参照してください。
yang-notif-native 形式
ソース ストリームが yang-notif-native の場合、NETCONF を介して XML でエンコードされるときの更新通知の形式は RFC 7950 によって定義されています。詳細については、RFC の 7.16.2 項を参照してください。
yang-push ストリームの形式とは異なり、サブスクリプション ID は更新通知にはありません。
gRPC プロトコル
gRPC プロトコルは、設定されたサブスクリプションのトランスポートにのみ使用でき、yang-push ストリームと yang-notif-native ストリームで使用できます。gRPC トランスポートプロトコルでは kvGPB エンコーディングのみがサポートされています
gRPC プロトコルに基づく受信者の接続の再試行(指数バックオフ)がサポートされています。
proto ファイルで定義されたテレメトリメッセージについては、 mdt_grpc_dialout.proto およびhttps://github.com/cisco-ie/cisco-proto/blob/9cc3967cb1cabbb3e9f92f2c46ed96edf8a0a78b/proto/xe/telemetry.prototelemetry.proto を参照してください。
テレメトリにおけるハイ アベイラビリティ
テレメトリの動的な接続は、アクティブなスイッチかスイッチスタック内のメンバーへの SSH、またはハイアベイラビリティ対応デバイスでのアクティブなルートプロセッサへの SSH を介して NETCONF セッションで確立されます。切り替え後は、テレメトリのサブスクリプションを伝送する NETCONF セッションを含め、暗号を使用するすべてのセッションを破棄し、再確立する必要があります。また、スイッチオーバー後にすべてのダイナミック サブスクリプションを再作成する必要があります。 gNMI ダイヤルイン サブスクリプションも、SSH を介したNETCONF セッションと同様に機能します。
gRPC ダイヤルアウト サブスクリプションは、アクティブなスイッチまたはスタック メンバの実行コンフィギュレーションの一部としてデバイスに設定されます。スイッチオーバーが発生すると、テレメトリ受信者への既存の接続が切断され、再接続されます(受信者へのルートが残っている限り)。サブスクリプションを再設定する必要はありません。
![]() (注) |
デバイスのリロード時には、サブスクリプションの設定をデバイスのスタートアップ コンフィギュレーションに同期させる必要があります。これにより、デバイスの再起動後もサブスクリプション設定がデバイス上にそのまま残ります。必要なプロセスが起動して実行されると、デバイスはテレメトリ受信者への接続を試行し、通常の動作を再開します。 |
サンプルのモデル駆動型テレメトリ RPC
次のセクションでは、RPC の例のリストを示し、サブスクリプションの設定方法について説明します。
設定済みサブスクリプションの管理
![]() (注) |
現在のところ、設定済みサブスクリプションの管理に使用できるのは gRPC プロトコルのみです。 |
手順の概要
- enable
- configure terminal
- telemetry ietf subscription id
- stream yang-push
- filter xpath path
- update-policy {on-change | periodic} period
- encoding encode-kvgpb
- source-vrf vrf-id
- source-address source-address
- receiver ip address ip-address receiver-port protocol protocol profile name
- end
手順の詳細
コマンドまたはアクション | 目的 | |
---|---|---|
ステップ 1 |
enable 例:
|
特権 EXEC モードを有効にします。
|
ステップ 2 |
configure terminal 例:
|
グローバル コンフィギュレーション モードを開始します。 |
ステップ 3 |
telemetry ietf subscription id 例:
|
テレメトリのサブスクリプションを作成し、テレメトリサブスクリプション モードを開始します。 |
ステップ 4 |
stream yang-push 例:
|
サブスクリプションのストリームを設定します。 |
ステップ 5 |
filter xpath path 例:
|
サブスクリプションの XPath フィルタを指定します。 |
ステップ 6 |
update-policy {on-change | periodic} period 例:
|
サブスクリプションの定期的な更新ポリシーを設定します。 |
ステップ 7 |
encoding encode-kvgpb 例:
|
kvGPB エンコードを指定します。 |
ステップ 8 |
source-vrf vrf-id 例:
|
ソースの VRF インスタンスを設定します。 |
ステップ 9 |
source-address source-address 例:
|
送信元アドレスを設定します。 |
ステップ 10 |
receiver ip address ip-address receiver-port protocol protocol profile name 例:
|
通知の受信者の IP アドレス、プロトコル、およびプロファイルを設定します。 |
ステップ 11 |
end 例:
|
テレメトリサブスクリプションのコンフィギュレーション モードを終了し、特権 EXEC モードに戻ります。 |
gRPC の変更時サブスクリプションの設定
手順の概要
- enable
- configure terminal
- telemetry ietf subscription id
- stream yang-push
- filter xpath path
- update-policy {on-change | periodic period}
- encoding encode-kvgpb
- receiver ip address ip-address receiver-port protocol protocol profile name
- end
手順の詳細
コマンドまたはアクション | 目的 | |
---|---|---|
ステップ 1 |
enable 例:
|
特権 EXEC モードを有効にします。
|
ステップ 2 |
configure terminal 例:
|
グローバル コンフィギュレーション モードを開始します。 |
ステップ 3 |
telemetry ietf subscription id 例:
|
テレメトリのサブスクリプションを作成し、テレメトリサブスクリプション モードを開始します。 |
ステップ 4 |
stream yang-push 例:
|
サブスクリプションのストリームを設定します。 |
ステップ 5 |
filter xpath path 例:
|
サブスクリプションの XPath フィルタを指定します。 |
ステップ 6 |
update-policy {on-change | periodic period} 例:
|
サブスクリプションの変更時更新ポリシーを設定します。 |
ステップ 7 |
encoding encode-kvgpb 例:
|
kvGPB エンコードを指定します。 |
ステップ 8 |
receiver ip address ip-address receiver-port protocol protocol profile name 例:
|
通知の受信者の IP アドレス、プロトコル、およびプロファイルを設定します。 |
ステップ 9 |
end 例:
|
テレメトリサブスクリプションのコンフィギュレーション モードを終了し、特権 EXEC モードに戻ります。 |
応答コードの受信
サブスクリプションが正常に作成されると、デバイスはサブスクリプション結果 notif-bis:ok およびサブスクリプション ID で応答します。次に、動的サブスクリプションの応答 RPC メッセージの例を示します。
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
<subscription-result xmlns="urn:ietf:params:xml:ns:yang:ietf-event-notifications"
xmlns:notif-bis="urn:ietf:params:xml:ns:yang:ietf-event-notifications">notif-bis:
ok</subscription-result>
<subscription-id xmlns="urn:ietf:params:xml:ns:yang:ietf-event-notifications">2147484201</subscription-id>
</rpc-reply>
NETCONF ダイヤルインのサブスクリプションプッシュ更新の受信
デバイスからプッシュされるサブスクリプション更新は XML RPC 形式であり、それらが作成された同じ NETCONF セッションにより送信されます。サブスクライブ対象情報の要素またはツリーは datastore-contents-xml タグ内で返されます。次に示すのは、サブスクライブ対象情報を提供するサンプル RPC メッセージです。
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2017-05-09T21:34:51.74Z</eventTime>
<push-update xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<subscription-id>2147483650</subscription-id>
<datastore-contents-xml>
<cpu-usage xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-process-cpu-oper"><cpu-utilization>
<five-minutes>5</five-minutes></cpu-utilization></cpu-usage>
</datastore-contents-xml>
</push-update>
</notification>
サブスクリプションが行われる情報要素が空である場合、またはそれが動的(名前付きアクセスリストなど)であり存在しない場合、定期更新は空になり、自己終結 datastore-contents-xml タグを持つことになります。次に示すのは、定期更新が空である RPC メッセージの例です。
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2017-05-09T21:34:09.74Z</eventTime>
<push-update xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<subscription-id>2147483649</subscription-id>
<datastore-contents-xml />
</push-update>
</notification>
サブスクリプションの詳細の取得
現在のサブスクリプションの一覧を取得するには、<get> RPC を Cisco-IOS-XE-mdt-oper モデルに送信します。現在のサブスクリプションの一覧を表示するには、show telemetry ietf subscription コマンドも使用できます。
次に、<get> RPC メッセージの例を示します。
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter>
<mdt-oper-data xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-mdt-oper">
<mdt-subscriptions/>
</mdt-oper-data>
</filter>
</get>
</rpc>
次に、RPC 応答の例を示します。
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
<data>
<mdt-oper-data xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-mdt-oper">
<mdt-subscriptions>
<subscription-id>2147485164</subscription-id>
<base>
<stream>yang-push</stream>
<encoding>encode-xml</encoding>
<period>100</period>
<xpath>/ios:native/router/ios-rip:rip/ios-rip:version</xpath>
</base>
<type>sub-type-dynamic</type>
<state>sub-state-valid</state>
<comments/>
<updates-in>0</updates-in>
<updates-dampened>0</updates-dampened>
<updates-dropped>0</updates-dropped>
</mdt-subscriptions>
</mdt-oper-data>
</data>
</rpc-reply>
次に、show telemetry ietf subscription dynamic brief コマンドの出力例を示します。
Device# show telemetry ietf subscription dynamic brief
Telemetry subscription brief
ID Type State Filter type
-----------------------------------------------------
2147483667 Dynamic Valid xpath
2147483668 Dynamic Valid xpath
2147483669 Dynamic Valid xpath
次に、show telemetry ietf subscription subscription-IDdetail コマンドの出力例を示します。
Device# show telemetry ietf subscription 2147483667 detail
Telemetry subscription detail:
Subscription ID: 2147483667
State: Valid
Stream: yang-push
Encoding: encode-xml
Filter:
Filter type: xpath
XPath: /mdt-oper:mdt-oper-data/mdt-subscriptions
Update policy:
Update Trigger: periodic
Period: 1000
Notes:
次に、show telemetry ietf subscription all detail コマンドの出力例を示します。
Device# show telemetry ietf subscription all detail
Telemetry subscription detail:
Subscription ID: 101
Type: Configured
State: Valid
Stream: yang-push
Encoding: encode-kvgpb
Filter:
Filter type: xpath
XPath: /iosxe-oper:ios-oper-db/hwidb-table
Update policy:
Update Trigger: on-change
Synch on start: Yes
Dampening period: 0
Notes:
次の RPC の例は、RESTCONF を使用してサブスクリプションの詳細を取得する方法を示します。
Subscription details can also be retrieved through a RESTCONF GET request to the Cisco-IOS-XE-mdt-oper database:
URI:
https://10.85.116.28:443/restconf/data/Cisco-IOS-XE-mdt-oper: mdt-oper-data/mdt-subscriptions
Headers:
application/yang-data.collection+json, application/yang-data+json, application/yang-data.errors+json
Content-Type:
application/yang-data+json
Returned output:
{
"Cisco-IOS-XE-mdt-oper:mdt-subscriptions": [
{
"subscription-id": 101,
"base": {
"stream": "yang-push",
"encoding": "encode-kvgpb",
"source-vrf": "",
"no-synch-on-start": false,
"xpath": "/iosxe-oper:ios-oper-db/hwidb-table"
},
"type": "sub-type-static",
"state": "sub-state-valid",
"comments": "",
"updates-in": "0",
"updates-dampened": "0",
"updates-dropped": "0",
"mdt-receivers": [
{
"address": "5.28.35.35",
"port": 57555,
"protocol": "grpc-tcp",
"state": "rcvr-state-connecting",
"comments": "Connection retries in progress",
"profile": ""
}
]
}
]
}
モデル駆動型テレメトリに関するその他の参考資料
関連資料
関連項目 | マニュアル タイトル |
---|---|
YANG エクスプローラ |
標準および RFC
標準/RFC | タイトル |
---|---|
イベント通知のカスタム サブスクリプション draft-ietf-netconf-subscribed-notifications-03 |
https://tools.ietf.org/id/draft-ietf-netconf-subscribed-notifications-03.txt |
イベント通知の NETCONF サポート |
|
RFC 5277 |
|
RFC 6241 |
|
RFC 7950 |
|
RFC 8040 |
|
イベント通知への登録 |
|
YANG データストア プッシュのサブスクライブ |
|
YANG データストア プッシュ更新のサブスクライブ draft-ietf-netconf-yang-push-07 |
https://tools.ietf.org/id/draft-ietf-netconf-yang-push-07.txt |
シスコのテクニカル サポート
説明 | リンク |
---|---|
シスコのサポート Web サイトでは、シスコの製品やテクノロジーに関するトラブルシューティングにお役立ていただけるように、マニュアルやツールをはじめとする豊富なオンライン リソースを提供しています。 お使いの製品のセキュリティ情報や技術情報を入手するために、Cisco Notification Service(Field Notice からアクセス)、Cisco Technical Services Newsletter、Really Simple Syndication(RSS)フィードなどの各種サービスに加入できます。 シスコのサポート Web サイトのツールにアクセスする際は、Cisco.com のユーザ ID およびパスワードが必要です。 |
モデル駆動型テレメトリの機能情報
次の表に、このモジュールで説明した機能に関するリリース情報を示します。この表は、ソフトウェア リリース トレインで各機能のサポートが導入されたときのソフトウェア リリースだけを示しています。その機能は、特に断りがない限り、それ以降の一連のソフトウェア リリースでもサポートされます。
プラットフォームのサポートおよびシスコ ソフトウェアイメージのサポートに関する情報を検索するには、Cisco Feature Navigator を使用します。Cisco Feature Navigator にアクセスするには、www.cisco.com/go/cfn に移動します。Cisco.com のアカウントは必要ありません。
機能名 |
リリース |
機能情報 |
---|---|---|
モデル駆動型テレメトリ NETCONF ダイヤルイン |
Cisco IOS XE Everest 16.6.1 |
モデル駆動型テレメトリでは、ネットワーク デバイスからサブスクライバに、リアルタイムの設定や運用状態の情報を継続的にストリームすることができます。
|
Cisco IOS XE Everest 16.6.2 |
|
|
Cisco IOS XE Fuji 16.7.1 |
|
|
Cisco IOS XE Fuji 16.8.1 |
|
|
Cisco IOS XE Fuji 16.8.1a |
|
|
Cisco IOS XE Fuji 16.9.1 |
|
|
Cisco IOS XE Gibraltar 16.9.2 |
|
|
Cisco IOS XE Gibraltar 16.10.1 |
|
|
Cisco IOS XE Gibraltar 16.11.1 |
|
|
モデル駆動型テレメトリ gNMI ダイヤルイン |
Cisco IOS XE Gibraltar 16.12.1 |
イニシエータ/サブスクライバに送信されるテレメトリの更新は、ダイヤルと呼ばれます。 この機能は、次のプラットフォームに実装されていました。
|
Cisco IOS XE Amsterdam 17.1.1 |
|
|
Cisco IOS XE Amsterdam 17.2.1 |
Cisco ASR 1000 シリーズ アグリゲーション サービス ルータ |
|
モデル駆動型テレメトリ gRPC ダイヤルアウト |
Cisco IOS XE Gibraltar 16.10.1 |
設置済みサブスクリプションでは、パブリッシャが受信者への接続を開始し、それらの接続はダイヤルアウトと見なされます。 この機能は、次のプラットフォームに実装されていました。
|
Cisco IOS XE Gibraltar 16.11.1 |
|
|
モデル駆動型テレメトリ:サブスクリプションの kill |
Cisco IOS XE Gibraltar 16.11.1 |
動的サブスクリプションを削除するには、CLI および kill-subscription RPC を使用できます。
|
TLDP 変更時の通知 |
Cisco IOS XE Amsterdam 17.2.1 |
TLDP 変更時の通知機能は、TLDP セッションが起動または停止したとき、および TLDP が設定またはディセーブルになったときにユーザに通知します。 この機能は、次のプラットフォームに実装されていました。
|
GRPC ダイヤルアウト用の TLS |
Cisco IOS XE Amsterdam 17.1.1 |
トランスポート層セキュリティは、gRPC ダイヤルアウトでサポートされます。この機能は、次のプラットフォームでサポートされます。
|