NETCONF および YANG API オーケストレーション
ガイド
公開済み
2023-07-07
リリース 4.2
導入
この文書の目的
このドキュメントでは、Control Center NETCONFおよびYANG APIを介してParagon Active Assuranceをネットワークサービスオーケストレーターと統合する方法について説明します。ハンズオン例amp仮想テスト エージェントの作成と展開、テストとモニターの実行、これらのアクティビティからの結果の取得など、関連する主なタスクに関するファイルが提供されます。
このドキュメントでは、無料で入手できる Python NETCONF クライアント ncclient がオーケストレーターの役割で使用されます。
コンベンション
このドキュメントでは次の略語が使用されています。
| 略語 | 意味 |
| コマンドライン | コマンドラインインターフェース |
| EM | 要素マネージャー |
| ES | エラー秒数 |
| 欧州議会議員 | MEG (メンテナンス エンティティ グループ) エンドポイント (ITU-T Y.1731 定義) またはメンテナンス エンドポイント (Cisco 定義) |
| NFV | ネットワーク機能の仮想化 |
| NFVO | ネットワーク機能仮想化オーケストレーター |
| NSDA の | ネットワーク サービス記述子 |
| RPC | リモート プロシージャ コール |
| SIP | セッション開始プロトコル |
| サービスレベル保証 | サービスレベル契約 |
| S-VNFM | 特別なVNFマネージャー |
| 仮想通貨 | 仮想ネットワーク機能 |
| 仮想TA | 仮想テストエージェント |
下位互換性に関する注意事項
NETCONF および YANG API のバージョン 2.35.4/2.36.0 では、NETCONF 標準に準拠するために、特定のリクエストの検証がより厳格になりました。つまり、このガイドの古いバージョンに基づくクライアント コードは拒否される可能性があります。
例えばample、以前のPython example コードでは、名前空間属性が指定されていません。ConfD リソースを変更するときは常に、要求 XML で名前空間を指定する必要があります。
前提条件と準備
ConfDのインストール
ConfD (Tail-f の製品) は、Paragon Active Assurance システムと NETCONF 間の仲介として使用されます。ConfD は、Paragon Active Assurance の構成と運用データを NETCONF および YANG API に接続します。
インストール ガイドに記載されているように、ConfD は Control Center ソフトウェアとともにインストールされている必要があります。
ConfD が実行中であることを確認する
ConfDが起動して実行されていることを確認するには、次のコマンドを実行します。
ssh -s @localhost -p 830 ネットコンフ
ConfDがポート830で応答することを確認します。コマンドでは、 netconfユーザー作成によって定義される
インストール ガイドの「ConfD のインストール」セクションのコマンドを使用します。同じコマンドで定義されたパスワードを入力します。
出力で、コントロール センター モジュールが含まれていることを確認します。出力には次のような行が含まれている必要があります。
http://ncc.netrounds.com?module=netrounds-ncc&改訂=2017-06-15
構成データベースをコントロールセンターと同期する
最後に、NETCONF を通じて構成データベースを更新する必要があります。ここでは、ncclient (NETCONF クライアント) と呼ばれる Python ライブラリを使用してこれを実行します。ただし、NETCONF/YANG プロトコルを使用する限り、このタスクは別のプログラミング言語でも実行できます。
ncclient の役割は、NETCONF/YANG API をホストする ConfD サーバーに対するクライアントとして機能することです。
名前が「ncc」で始まっていますが、ncclient は Control Center (以前の「Netrounds Control Center」) とはまったく関係がないことに注意してください。
ncclient をインストールする方法は次のとおりです。
- ソフトウェアをダウンロードするには https://github.com/ncclient/ncclient.
- このコマンドを実行します: pip install ncclient
次のように同期を実行できます。これは、コントロール センター サーバー自体ではなく、別のコンピューターで実行する必要があることに注意してください。
#
＃ 注記：
# このスクリプトは、NCC サーバー上で実行されている ConfD に対するクライアントとして機能します。
# 通信には NETCONF/YANG API を使用します。
注記: この手順は、NETCONFとは別にテストエージェントをインストールして登録した場合にも必要です。「view 詳細については、17 ページの「テスト エージェント オーケストレーションの概要」を参照してください。
複数の NETCONF 制御 Paragon Active Assurance アカウントの設定
以下の手順は、インストール ガイドの「ConfD のインストール」セクションでこの方法で設定されたアカウントに加えて、NETCONF によって制御される追加の Paragon Active Assurance アカウントを設定する場合にのみ必要です。
各アカウントごとに、次の手順を実行します。
- コントロール センターでアカウントにログインし、[アカウント] > [権限] に移動します。
- ユーザー「メール:「」をクリックし、「招待」ボタンをクリックして GUI でこの ConfD ユーザーに管理者権限を付与します。
- 4 ページの「構成データベースとコントロール センターの同期」のセクションの説明に従って、構成データベースをコントロール センターと同期します。
これで、同じ ConfD ユーザーで複数の Paragon Active Assurance アカウントを制御できるようになります。
注記: ConfD経由でParagon Active Assuranceアカウントの管理を開始したら、 web 「config」である Paragon Active Assurance 機能に関する GUI (9 ページの「Paragon Active Assurance でサポートされる機能」の章を参照)。これを実行すると、同期が失われます。
NETCONF オーケストレーション API の紹介
以上view
サードパーティの NFVO またはサービス オーケストレーターは、通常、コントロール センター API を使用してテストおよび監視セッションを開始するコンポーネントです。このオーケストレーターは、テスト エージェント アクティビティから集計された測定結果も取得します。パフォーマンス KPI はサードパーティのパフォーマンス管理システムによって取得できます。一方、コントロール センターで設定されたしきい値違反によってトリガーされたイベントは、サードパーティの障害管理システムに送信できます。
要約すると、下の図は Paragon Active Assurance が OSS 環境内の他のサードパーティ システムとどのように相互作用するかを示しています。
- NFVO/サービス オーケストレーター: VNF マネージャーに vTA を展開し、サービス チェーンに Paragon Active Assurance を構成するように指示します。サービスがアクティブ化されると、オーケストレーターはコントロール センターへの API を使用してサービス アクティベーション テストをトリガーし、合格/不合格の結果を取得します。テストに合格すると、オーケストレーターはコントロール センターへの API を使用してサービスのアクティブ モニタリングを開始します。モニタリングからの KPI は、オーケストレーターまたは別のパフォーマンス管理プラットフォームによって継続的に取得されます。
- コントロール センター: NFVO またはサービス オーケストレーターの指示に従って vTA を展開、拡張、終了します。
- パフォーマンス管理システムまたはサービス品質管理システム: コントロール センター API を介してアクティブな監視から KPI を読み取ります。
- 障害管理システム: SLA に違反した場合、コントロール センターから NETCONF、SNMP、または電子メール通知を受信します。
Paragon Active Assurance の概念の定義
- テスト エージェント: Paragon Active Assurance システムで測定 (テストおよびモニター用) を実行するコンポーネント。テスト エージェントは、実際のネットワーク トラフィックを生成、受信、および分析する機能を備えたソフトウェアで構成されています。
- このドキュメントで説明するテスト エージェントの種類は、ハイパーバイザーに展開される仮想ネットワーク機能 (VNF) である仮想テスト エージェント (vTA) です。他の種類のテスト エージェントも存在します。
- Paragon Active Assurance には、テストとモニターの 2 つの基本的な測定タイプがあります。
- テスト: テストは 1 つまたは複数のステップで構成され、各ステップには指定された有限の期間があります。ステップは順番に実行されます。各ステップでは、複数のタスクを同時に実行する必要がある場合があります。
- モニター: モニターには指定された期間がなく、無期限に実行されます。テストのステップと同様に、モニターは複数の同時タスクを実行する場合があります。
- テンプレート: Paragon Active Assurance がオーケストレーターによって制御されている場合、テストとモニターは常に、テストまたはモニターが定義されているテンプレートを使用して実行されます。パラメーター設定は、実行時にテンプレートへの入力として渡すことができます。
自動化のためのワークフロー
設計時間
設計時に、Paragon Active Assurance でテストとモニターのテンプレートを作成し、測定を準備します。その方法については、15 ページの「テストとモニターのテンプレート」の章で説明します。
ランタイム
実行時に、デバイスをセットアップして実際の測定を実行します。
- オーバーview すべての元amp与えられた説明は「例amp15 ページの「NETCONF および YANG API 経由で Paragon Active Assurance を制御する」を参照してください。
- テストエージェントの導入と設定方法については、「Examp「レス: エージェントのテスト」(16 ページ)。
- TWなどの在庫品目をインポートする方法AMP リフレクターとIPTVチャンネルについては、「Examp29 ページの「付録: 在庫品目」を参照してください。
- アラームの設定方法については、「例」の章で説明されています。amp35 ページの「アラーム」を参照してください。
- NETCONFを介してParagon Active Assuranceテンプレートを実行してテストとモニターを実行する方法については、「例」の章で説明します。amp43ページの「例: テスト」とXNUMXページの「例: テスト」amp54 ページの「付録：モニター」を参照してください。
Paragon Active Assuranceでサポートされている機能
Paragon Active Assurance のすべてのテストおよびモニター タイプは、テンプレートを使用して作成および実行できます。これを行う方法については、アプリ内ヘルプの「テストとモニター」>「テンプレートの作成」で説明されています。
Paragon Active Assurance アカウントの作成は現在サポートされていませんが、ユーザーに対して 1 つまたは複数の定義済みアカウントが設定されます。
以下の表は、このリリースで利用できる Paragon Active Assurance の機能と、これらの機能が YANG でどのように表現されるかを詳しく説明しています。
YANGコンストラクトの説明
便宜上、機能テーブルで参照される YANG 構成要素の定義をここに示します。
- 構成 (config=true): システムをある状態から別の状態に変換するために必要な構成データ。
- 状態 (config=false): 状態データ: 読み取り専用のステータス情報や収集された統計など、構成データではないシステム上の追加データ。
- RPC: NETCONF プロトコル内で使用されるリモート プロシージャ コール。
- 通知: NETCONF サーバーから NETCONF クライアントに送信されるイベント通知。
オーケストレーションに使用できる Paragon Active Assurance 機能の表
リソース: 監視
YANG パス:/accounts/account/monitors
| 特徴 | サブ機能 | YANG構造 |
| モニターの作成/変更/削除 | モニターテンプレートに基づく | 設定 |
| モニターの開始/停止 | – | 設定 |
| モニターテンプレート | 既存のモニターテンプレートを入力とともに一覧表示する | 州 |
| NETCONF通知 | アラーム状態が変更されました | 通知 |
| 結果を監視する | トップレベルの SLA/ES カウンター (%) タスク レベルの SLA/ES カウンター (%) |
州 |
テストとは異なり (以下のリソース: テストと比較)、モニターは RPC で開始されるのではなく、モニター構成をコミットすることによって開始されます。
リソース: テスト
YANG パス: /accounts/account/tests
| 特徴 | サブ機能 | YANG構造 |
| テストを開始 | テストテンプレートに基づく | RPC |
| テストを管理する | ステータス付きテストの一覧 | 州 |
| テストテンプレート | 既存のテストテンプレートを入力とともに一覧表示する | 州 |
| NETCONF通知 | テストステータスが変更されました | 通知 |
| テスト結果 | テストステップのステータスを取得します（合格、不合格、エラーなど） | 州 |
リソース: テストエージェント
YANG パス:
- /accounts/account/test-agents (設定)
- /accounts/account/registered-test-agents (状態)
/accounts/account/test-agents の下にあるテスト エージェントは、アカウント内で構成されているものです。これらのテスト エージェントのみ、オーケストレーターによって NETCONF 経由で構成され、テストおよびモニターで使用できます。
テストエージェントを設定し、アカウントに登録すると、テストエージェントは /accounts/account/registered-test-agents の下に表示されます。登録されているすべてのテストエージェントは、NETCONF の「get」コマンドを使用して見つけることができます (例:amples: テストエージェント。
/accounts/account/registered-test-agents の下には、まだ構成されていないテスト エージェントも見つかる場合があります。このようなテスト エージェントは、使用する前に構成する必要があります。
オーケストレーション シナリオでは、通常、Paragon Active Assurance アカウントのすべての構成を NETCONF 経由で実行することをお勧めします。これにより、テスト エージェントと登録済みテスト エージェントが分岐しなくなります。
| 特徴 | サブ機能 | YANG構造 |
| サーバー上にテストエージェントを事前に作成する | – | 設定 |
| オフライン テスト エージェントを構成する | （コントロールセンターはテストエージェントに構成をプッシュします オンラインになったとき |
設定 |
| 既存または外部で構成されたテストエージェントを使用する | テスト/モニターでの使用 | 設定 |
| インターフェイスを構成する | 設定 | |
| ステータスを取得 | 州 | |
| テスト エージェントを構成する (テスト アプライアンスのみ) | NTP の構成 | 設定 |
| ブリッジを構成する | 設定 | |
| VLANインターフェースを構成する | 設定 | |
| SSHキーを設定する | 設定 | |
| IPv6 | 設定 | |
| ユーティリティ | リブート | RPC |
| アップデート | RPC | |
| NETCONF通知 | オンラインステータスが変更されました | 通知 |
| 状態 | システムステータス（稼働時間、メモリ使用量、 負荷平均、バージョン) |
州 |
リソース: 在庫
YANG パス: /accounts/account/twamp-リフレクター
サポートされている NETCONF 機能
以下の表は、Paragon Active Assurance オーケストレーションの目的で使用される NETCONF 機能を説明する IETF RFC を示しています。
- ietf-netconf.yang
- IETF RFC 6241、ネットワーク構成プロトコル (NETCONF)、 https://tools.ietf.org/html/rfc6241
- サポートされている唯一のエラー処理方法は、rollback-on-error です。
- サポートされているデータ ストアは書き込み可能で実行可能なもののみです。
- ietf-netconf-通知.yang
- IETF RFC 5277、NETCONFイベント通知、 https://tools.ietf.org/html/rfc5277
テストおよび監視テンプレート
テストおよびモニター タイプのテンプレートは、Paragon Active Assurance フロントエンド ユーザー インターフェイスから手動で設定する必要があります。設定方法については、アプリ内ヘルプの「テストとモニター」>「テンプレートの作成」で説明されています。
ExampNETCONF および YANG API による Paragon Active Assurance の制御の例
以降の章では、15 ページの「テストおよびモニター テンプレート」の章の指示に従って適切なテストおよびモニター テンプレートが定義されていることを前提としています。
Exで使用されるツールampレ
すべての元amp以降の章のファイルは、以下の無料で利用できるツールを使用して作成されています。
- Pang: YANG モデルを視覚化および参照するために使用されます。
- 入手可能 https://github.com/mbj4668/pyang (git からクローンし、python setup.py install を実行します)。
- Python NETCONF クライアント「ncclient」: NETCONF を使用してコントロール センターと通信するために使用されます。
- https://github.com/ncclient/ncclient で入手可能 (pip install ncclient を実行)。
ConfD がインストール ガイドに従ってインストールされると、netrounds-ncc.yang データ モデルは /opt/netrounds-confd にあります。
以上view 実行された主要タスク
(以下に、さらにいくつかのタスクの例も示します。)
- 「新しいテストエージェントの作成と展開」16ページ
- 「在庫品目（リフレクターなど）の作成」29ページ
- 「アラームテンプレートの設定とアラームの送信先」（35ページ）
- 「テストの作成と実行」45ページ
- 「テスト結果の取得」50ページ
- 「モニターの起動（アラームの設定を含む）」60ページ
- 「モニターのSLAステータスの取得」67ページ
- 「 tags」（71ページ）
Examples: テストエージェント
以上view テストエージェントオーケストレーション
Paragon Active Assurance のテスト エージェントは、オーケストレーションのコンテキストでは「構成」と見なされます。つまり、テスト エージェントの作成、制御、削除は、Paragon Active Assurance GUI ではなく、オーケストレーターと NETCONF を介して実行する必要があります。
重要: テスト エージェントが技術者によってインストールされ、NETCONF および YANG API 経由で作成されずにコントロール センターに登録された場合、テスト エージェントは構成データベースに存在せず、システムは同期されなくなります。この場合、ConfD がテスト エージェントを認識するには、4 ページの「構成データベースとコントロール センターの同期」のセクションで詳しく説明されているように、コントロール センターとの新しい同期を実行する必要があります。
したがって、仮想テスト エージェント (vTA) のオーケストレーションは、次の手順で実行する必要があります。
- コントロール センターへの NETCONF および YANG インターフェイスを使用して、インターフェイス構成を含む仮想テスト エージェントを作成します。テスト エージェントの名前は、その一意のキーになります。
- vTA を仮想化プラットフォームに展開します。オンライン ヘルプの「テスト エージェント > インストール」の指示に従ってください。vTA がコントロール センターに接続できるようにする基本的なインターフェイス構成と、認証用の資格情報は、cloud-init ユーザー データを使用して vTA に提供されます。
vTA が起動すると、暗号化された OpenVPN 接続を使用してコントロール センターに自動的に接続します。vTA の test-agent-statuschange パラメータの値が「online」に変更されたため、NETCONF 通知が送信されます。
注記: vTA の名前はコントロール センターでの識別子であるため、この名前は 1 ページの「手順 17」でコントロール センターで定義した名前と同じである必要があります。 - vTA がコントロール センターに接続して認証されると、インターフェイス設定が vTA にプッシュされます。これは、コントロール センターで vTA が作成されたときに 1 ページの「手順 17」で提供されたインターフェイス設定です。
- vTA の目的を果たした後は、vTA を削除します。
新しいテストエージェントの作成と展開
まず、コントロール センターへの NETCONF および YANG インターフェイスを使用してテスト エージェントを作成する必要があります。この方法でテスト エージェントを作成すると、コントロール センターとの同期は必要ありません。
テストエージェントのYANGモデルは以下のとおりです。これはコマンドの出力として取得されます。
pyang -f ツリー netrounds-ncc.yang
完全な YANG モデルは、81 ページの「付録: 完全な YANG モデルのツリー構造」に記載されています。この図には、このモデルおよび本書の他の YANG モデルの図で使用される規則を説明する凡例も含まれています。
次の手順で進めていきます。詳細は以下のとおりです。
- 最初は、Paragon Active Assurance アカウント「デモ」のインベントリにはテスト エージェントが含まれていません。
- ncclientを使用して「vta1」というテストエージェントが作成されます。この時点でtagつまり、実際のテスト エージェントはまだ存在しません (つまり、まだ起動されていません)。
- テスト エージェントは OpenStack にデプロイされます。(このプラットフォームへのデプロイは、他の可能性の 1 つとしてここで選択されています。)
- テスト エージェントはコントロール センター アカウント「demo」に接続し、使用できるようになります。
ステップ 1: 最初は、アカウント「demo」にテスト エージェントは存在しません。コントロール センター GUI の以下のスクリーンショットを参照してください。
ステップ 2: Python NETCONF クライアント「ncclient」を使用して、コントロール センターにテスト エージェントが作成されます。以下は、DHCP アドレスを持つ XNUMX つの物理インターフェイスを持つテスト エージェントを作成するための ncclient コードです。
argparseをインポートする
ncclientインポートマネージャから
parser = argparse.ArgumentParser(description='テストエージェントを作成しているテスト')
parser.add_argument('–host', help='ConfD が見つかるホスト名', required=True)
parser.add_argument('–port', help='ConfD に接続するポート', required=True)
parser.add_argument('–username', help='ConfD に接続するためのユーザー名', required=True)
parser.add_argument('–password', help='ConfD アカウントのパスワード', required=True)
parser.add_argument('–netrounds-account', help='NCC アカウントの短縮名', required=True)
parser.add_argument('–test-agent-name', help='テストエージェントの名前', required=True)
引数 = パーサー.parse_args()
manager.connect(host=args.host, port=args.port, username=args.username, で
password=args.password、hostkey_verify=False) を m として:
# コントロールセンターでテストエージェントを作成する
xml = “””
)m.edit_config を印刷します(target='running'、config=xml)
注記: manager.connect(…) の前のコードは後続のexから省略されますampコードスニペット。
NTP サーバーは eth0 に設定されており、eth0 は管理インターフェイス (つまり、コントロール センターに接続するインターフェイス) でもあります。
テスト エージェント アプリケーションでは、現在インターフェイスの構成は許可されていません。このため、バージョン 2.34.0 以降では、YANG スキーマでインターフェイス構成を省略できます。この場合、対応する XML は大幅に簡素化されます。
テスト エージェントが作成されると、構成データベースとコントロール センターに存在します。テスト エージェント インベントリの以下のスクリーンショットを参照してください。テスト エージェント「vta1」が表示されています。
ステップ 3: ここで、OpenStack にテスト エージェント「vta1」をデプロイします。
テストエージェントは、クラウド初期化ユーザーデータを使用して、コントロールセンターへの接続方法に関する情報を取得します。具体的には、ユーザーデータテキスト file 内容は次のようになります (#cloud-config および netrounds_test_agent 行が存在する必要があり、残りの行はインデントする必要があることに注意してください)。
詳細については、「OpenStack で仮想テスト エージェントをデプロイする方法」のドキュメントを参照してください。
テスト エージェントがデプロイされ、コントロール センターに接続されると、構成がコントロール センターからテスト エージェントにプッシュされます。
ステップ 4: テスト エージェントがコントロール センターでオンラインになり、構成を取得しました。テスト エージェントは、テストと監視に使用できる状態です。次のセクションを参照してください。
- 「テストの開始」45ページ
- 「モニターの起動」60ページ
Paragon Active Assurance アカウントのテスト エージェントの一覧表示
以下は例ですampParagon Active Assurance アカウント内のテスト エージェントを一覧表示するための le ncclient Python コード:
このコードを実行すると、以下のような出力が得られます。
テストエージェントの削除
テストが完了した後、一部のユースケースではテスト エージェントを削除することが必要な場合があります。
以下は、ncclient を使用してこれを行う方法を示すコード スニペットです。
NETCONF 通知
以下に簡単な例を示します。ampコントロール センターからのすべての受信 NETCONF 通知をリッスンするためのスクリプトです。これらの通知は、テスト エージェントがオフラインになったり、ユーザーが開始したテストが完了したりするなど、特定のイベントが発生するたびに送信されます。通知に含まれる情報に基づいて、ユーザーはオーケストレーターで自動化されたフォローアップ アクションを割り当てることができます。
上記のスクリプトが実行されると、NCクライアントは受信した通知を構造化されたXMLで表示します。例を参照してください。amp以下の出力は、テスト エージェントが予期せずオフラインになったことを示しています。
2017-02-03T15:09:55.939156+00:00</eventTime>
<test-agent-status-change xmlns=’http://ncc.netrounds.com'>
デモ
1 位
オフライン
Examples: 在庫品目
TWなどの在庫品目の作成（インポート）と管理AMP リフレクタと Y.1731 MEP の定義は、テスト エージェントの場合と同様の方法で行われます。以下は、NETCONF および YANG API を介して Paragon Active Assurance でこのようなエンティティを定義し、定義された項目のリストを取得するための XML および NETCONF コードです。
TWの作成AMP リフレクター
Y.1731 MEP の作成
IPTVチャンネルの作成
Pingホストの作成
SIP アカウントの作成
在庫品の取得
以下は、アカウントで定義されているすべての在庫項目を取得するための Python コードです。(ドキュメント内での重複を避けるため、ここではすべての種類の在庫項目を一度に取得しています。当然、以下のアカウントの下の行の一部を省略することで、在庫項目のサブセットを取得できます。)
このコードを実行すると、以下のような出力が得られます。
Examples: アラーム
アラーム テンプレートと関連項目 (SNMP マネージャー、アラーム電子メール リスト) は、インベントリ項目と同様の方法で作成および管理されます。この章には、NETCONF および YANG API を介して Paragon Active Assurance でこのようなエンティティを定義し、定義された項目のリストを取得するための XML および NETCONF コードが含まれています。
アラームメールリスト
アラームメールリストの作成
すべてのアラームメールリストを取得
SNMP マネージャー
SNMP マネージャーの作成
すべてのSNMPマネージャーの取得
アラームテンプレート
アラームテンプレートの作成
すべてのアラームテンプレートを取得
Examples: SSH キー
NETCONF および YANG API を介して、テスト エージェントに SSH 公開キーを追加できます。対応する秘密キーを使用して、SSH 経由でテスト エージェントにログインできます。
SSH キーで利用可能な操作の完全なリストは次のとおりです。
- SSHキーを追加する
- SSHキーを変更する
- SSHキーを検査する
- SSHキーの一覧
- SSH キーを削除します。
以下に、追加および削除操作の例を示します。
SSH キーの削除
SSH キーを削除する場合は、次のコマンドを使用します。
Examples: テスト
ここでは、17 ページの「新しいテスト エージェントの作成と展開」のセクションに従って、テスト エージェント (テストに必要な数だけ) が作成されていることを前提としています。
テスト用の YANG モデル パス
| アイテム | YANG モデル パス: /accounts/account/tests … |
| テスト | /. |
| テスト[id] | /テスト |
| id | /テスト/id |
| 名前 | /テスト/名前 |
| 状態 | /テスト/ステータス |
| 始まる時間 | /テスト/開始時間 |
| 終了時間 | /テスト/終了時間 |
| 報告-url | /試験報告書-url |
| 手順 | /テスト/ステップ |
| ステップ[id] | /テスト/ステップ/ステップ |
| 名前 | /テスト/ステップ/ステップ名 |
| id | /テスト/ステップ/ステップ/id |
| 始まる時間 | /テスト/ステップ/ステップ/開始時間 |
| 終了時間 | /テスト/ステップ/ステップ/終了時間 |
| 状態 | /テスト/ステップ/ステップ/ステータス |
| ステータスメッセージ | /テスト/ステップ/ステップ/ステータスメッセージ |
| テンプレート | /テンプレート |
| テンプレート[名前] | /テンプレート/テンプレート |
| 名前 | /テンプレート/テンプレート/名前 |
| 説明 | /テンプレート/テンプレート/説明 |
| パラメータ | /テンプレート/テンプレート/パラメータ |
| パラメータ[キー] | /テンプレート/テンプレート/パラメータ/パラメータ |
| 鍵 | /templates/テンプレート/パラメータ/パラメータ/キー |
| タイプ | /テンプレート/テンプレート/パラメータ/パラメータ/タイプ |
テストオーケストレーションの前提条件
- NC クライアントを使用して NETCONF 経由でテストを開始するには、まず、アプリ内ヘルプの「テストとモニター」>「テンプレートの作成」で説明されているように、コントロール センター GUI を使用してテスト テンプレートを作成する必要があります。そのテンプレートで「テンプレート入力」として指定されているすべてのフィールドは、テスト テンプレートの開始をオーケストレーションするときに XML のパラメーターとして必要になります。
- Paragon Active Assuranceでテストを実行することは、オーケストレーションのコンテキストでは「状態」と見なされます。状態データは、構成データベースに保存されない書き込み不可能なデータであり、「概要」のセクションで説明した構成データとは異なります。view 17 ページの「テスト エージェント オーケストレーションの概要」を参照してください。これは基本的に、コントロール センター GUI でテストまたはテンプレートを変更しても、コントロール センターと構成データベースの間で同期関連の問題が発生しないことを意味します。
- レポートを取得するにはURL テストレポートで正しく機能するには、コントロールセンターが URL 正しく設定されていることを確認します。これは file /opt/netrounds-confd/settings.py。デフォルトでは、コントロールセンターのホスト名はsocket.gethostname()を使用して取得されます。以下を参照してください。これで正しい結果が得られない場合は、ホスト名（またはホスト名全体）を設定する必要があります。 URL）を手動で file.
# URL コントロール センターの末尾のスラッシュなし。
# これは例ですampテストレポートで使用されるle-url.
ホスト名 = socket.gethostname()
ネットラウンド_URL = 'https://%s' % ホスト名
テストの開始
17ページの「新しいテストエージェントの作成と展開」のセクションで説明したように、コマンドpang -f tree netrounds-ncc.yangを実行します。
YANG モデルを出力するために、ディレクトリ /opt/netrounds-confd/ から実行します。このモデルでは、NC クライアントを使用してテストを開始するための RPC は次のようになります。
説明については、セクションを参照してください。 81ページの「凡例」 付録に記載されています。
次の手順を以下に示します。
- テスト エージェントは Paragon Active Assurance アカウントに登録されていますが、テストはまだ開始されていません。
- 必要な入力パラメータは、実行されるテスト テンプレートで識別されます。
- ncclient を使用して 60 秒間の HTTP テストが開始されます。
ステップ 1: 最初は、Paragon Active Assurance アカウントでテストが開始されていません。以下のコントロール センター GUI のスクリーンショットを参照してください。
ステップ 2: この例でテストを開始するために使用するテンプレートampleはHTTPテストテンプレートです。必須の入力フィールドが2つあります（クライアントと URL) は、コントロール センター GUI でテンプレートを作成するときに指定したものです。
これらのパラメータは、NETCONF マネージャー (ncclient) によって構成データベースに伝達される XML 構成で定義します。
ステップ 3: ncclient を使用して HTTP テストが開始されます。
以下は例ですampHTTP テスト テンプレートに必要な構成情報とパラメータが指定されているファイル コード。テンプレートの構築方法に応じて、ここでの詳細は異なる場合があります。
各パラメータについて、属性を指定する必要があります。キーはパラメータの
コントロール センターの変数名。変数名は次のようにして調べることができます。
- サイドバーの「テスト」をクリックし、「新しいテスト シーケンス」を選択します。
- [マイテンプレート]をクリックします。
- 関心のあるテンプレートの下にある「編集」リンクをクリックします。
- 右上隅にある入力の編集ボタンをクリックします。
私たちの元ampデフォルトでは、変数名はコントロールセンターに表示される表示名の小文字バージョン（「url」対「URLただし、コントロール センターの GUI では、変数の名前を任意の名前に変更できます。
キーの他に、各パラメータにはその型を指定する必要があります。例:ampル、のために URL.
再度確認する必要があることに注意してくださいview 完全なYANGモデルを使用して、型に関する完全な情報を取得します。テストエージェントインターフェースの場合、型はより複雑な構造を持ちます。以下のコードをご覧ください。
これで、ncclient を使用してスクリプトを実行できます。すべてが正しければ、テストが開始され、その実行がコントロール センターに表示されます。
テストが正常に開始されると、コントロールセンターはテストIDを返します。この例ではample、テストIDは3です:
テストIDは、 URL コントロールセンターGUIでのテスト用。この例ではampえ、それ URL は https://host/demo/testing/3/ です。
テスト結果の取得
テスト結果を取得する最も簡単な方法は、テスト ID を指定することです。
以下は、ID = 3 の上記の HTTP テストから結果を取得するための Python コードです。
マネージャーで、m として Connect(host=args.host、port=args.port、username=args.username、password=args.password、hostkey_verify=False) を実行します。
出力は次のようになります。
テストテンプレートのエクスポートとインポート
テスト テンプレートは JSON 形式でエクスポートし、その形式で Control Center に再インポートできます。これは、Control Center の別のインストールでテスト テンプレートを使用する場合に便利です。(テンプレートの初期作成は、Control Center GUI を通じて行うのが最適です。)
以下はエクスポートとインポートを実行するためのコードです。
テストテンプレートのエクスポート
# レスポンスからJSON設定を取得する
ルート = ET.fromstring(response._raw)
json_config = ルート[0].テキスト
json_config を印刷する
テンプレートは json_config オブジェクトに含まれています。
テストテンプレートのインポート
テスト テンプレートを保持する JSON 構成オブジェクトは、次のようにしてコントロール センターに再インポートできます。
Examples: モニター
このセクションでは、17 ページの「新しいテスト エージェントの作成と展開」セクションに従ってテスト エージェント (モニターに必要な数だけ) が作成されていることを前提としています。
モニターの YANG モデル パス
| アイテム | YANG モデル パス: /accounts/account/monitors … |
| モニター | /. |
| モニター[名前] | /モニター |
| 名前 | /モニター/名前 |
| 説明 | /モニター/説明 |
| 開始 | /モニター/開始 |
| テンプレート | /モニター/テンプレート |
| アラーム設定 | /モニター/アラーム設定 |
| アイテム | YANG モデル パス: /accounts/account/monitors/monitor/alarm-configs … |
| アラーム設定[識別子] | /アラーム設定 |
| 識別子 | /アラーム設定/識別子 |
| テンプレート | /アラーム設定/テンプレート |
| メール | /アラーム設定/メール |
| SNMP の | /アラーム設定/snmp |
| 非常に重要 | /アラーム設定/thr-es-critical |
| クリア | /アラーム設定/重大なクリア |
| 3番目の | /アラーム設定/メジャー |
| 晴れ | /アラーム設定/メジャークリア |
| 3 番目 | /アラーム設定/マイナー |
| スレ-エス-マイナー-クリア | /アラーム設定/マイナークリア |
| 警告 | /アラーム設定/警告 |
| 警告クリア | /アラーム設定/警告クリア |
| データなしの重大度 | /アラーム設定/データなし重大度 |
| データタイムアウトなし | /アラーム設定/データタイムアウトなし |
| アクション | /アラーム設定/アクション |
| ウィンドウサイズ | /アラーム設定/ウィンドウサイズ |
| 間隔 | /アラーム設定/間隔 |
| 一度だけ送信 | /アラーム設定/一度だけ送信 |
| ストリームごとの snmp トラップ | /アラーム設定/ストリームごとのSNMPトラップ |
| アイテム | YANG モデル パス: /accounts/account/monitors … |
| パラメータ | /モニター/パラメータ |
| アイテム | YANG モデル パス: /accounts/account/monitors/monitor/parameters … |
| パラメータ[キー] | /パラメータ |
| 鍵 | /パラメータ/キー |
| (値タイプ) | /パラメータ |
| ：（整数） | /パラメータ |
| 整数 | /パラメータ/整数 |
| ：（浮く） | /パラメータ |
| フロート | /パラメータ/浮動小数点数 |
| ：（弦） | /パラメータ |
| アイテム | YANG モデル パス: /accounts/account/monitors/monitor/parameters … |
| 弦 | /パラメータ/文字列 |
| :(テストエージェントインターフェース) | /パラメータ |
| テストエージェントインターフェース | /パラメータ/テストエージェントインターフェース |
| test-agent-interface[“1” 58ページ | /パラメータ/テストエージェントインターフェース/ |
| アカウント | /パラメータ/テストエージェントインターフェース/テストエージェントインターフェース/アカウント |
| テストエージェント | /パラメータ/テストエージェントインターフェース/テストエージェントインターフェース/テストエージェント |
| インタフェース | /パラメータ/テストエージェントインターフェース/テストエージェントインターフェース/インターフェース |
| IP バージョン | /パラメータ/テストエージェントインターフェース/テストエージェントインターフェース/IPバージョン |
| :(twamp-リフレクター) | /パラメータ |
| twamp-リフレクター | /パラメータ/twamp-リフレクター |
| twamp-リフレクター[名前] | /パラメータ/twamp-リフレクター/twamp-リフレクター |
| 名前 | /パラメータ/twamp-リフレクター/twamp-リフレクター/名前 |
| :(y1731-meps) | /パラメータ |
| y1731-メップス | /パラメータ/y1731-meps |
| y1731-mep[名前] | /パラメータ/y1731-meps/y1731-mep |
| 名前 | /パラメータ/y1731-meps/y1731-mep/名前 |
| :(SIP アカウント) | /パラメータ |
| SIP アカウント | /パラメータ/sipアカウント |
| sip-account[2ページの「58」] | /パラメータ/sipアカウント/sipアカウント |
| アカウント | /パラメータ/sip-accounts/sip-account/アカウント |
| テストエージェント | /パラメータ/sip-accounts/sip-account/テストエージェント |
| インタフェース | /パラメータ/sipアカウント/sipアカウント/インターフェース |
| SIPアドレス | /パラメータ/sipアカウント/sipアカウント/sipアドレス |
| :(iptv チャンネル) | /パラメータ |
| IPTVチャンネル | /パラメータ/iptv-チャンネル |
| iptv-チャンネル[名前] | /パラメータ/iptv-チャンネル/iptv-チャンネル |
| 名前 | /パラメータ/iptv-チャンネル/iptv-チャンネル/名前 |
- アカウント テスト エージェント インターフェイス
- アカウント テストエージェント インターフェイス SIP アドレス
| アイテム | YANG モデル パス: /accounts/account/monitors … |
| 状態 | /モニター/ステータス |
| 最後の15分 | /モニター/ステータス/過去15分 |
| 状態 | /モニター/ステータス/過去15分/ステータス |
| ステータス値 | /モニター/ステータス/過去15分/ステータス値 |
| 最後の時間 | /モニター/ステータス/過去1時間 |
| 状態 | /モニター/ステータス/過去1時間/ステータス |
| ステータス値 | /モニター/ステータス/過去1時間/ステータス値 |
| 過去24時間 | /モニター/ステータス/過去24時間 |
| 状態 | /モニター/ステータス/過去24時間/ステータス |
| ステータス値 | /モニター/ステータス/過去24時間/ステータス値 |
| テンプレート | /テンプレート |
| テンプレート[名前] | /テンプレート/テンプレート |
| 名前 | /テンプレート/テンプレート/名前 |
| 説明 | /テンプレート/テンプレート/説明 |
| パラメータ | /テンプレート/テンプレート/パラメータ |
| パラメータ[キー] | /テンプレート/テンプレート/パラメータ/パラメータ |
| 鍵 | /templates/テンプレート/パラメータ/パラメータ/キー |
| タイプ | /テンプレート/テンプレート/パラメータ/パラメータ/タイプ |
モニターオーケストレーションの前提条件
ncclient を使用して NETCONF 経由でモニターを開始する前に、アプリ内ヘルプの「テストとモニター」>「テンプレートの作成」で説明されているように、コントロール センター GUI でモニター テンプレートを作成する必要があります。そのテンプレートで「テンプレート入力」として指定されたすべてのフィールドは、テンプレートの開始をオーケストレーションするときに XML のパラメーターとして必要になります。
モニターテンプレートから入力パラメータを取得する
以下に 2 つのテンプレートを示します。1 つ目は 2 つの Test Agent インターフェイス間の UDP 監視用で、2 つ目は単一の Test Agent インターフェイスを使用する HTTP 用です。
テンプレートの入力パラメータを確認するには、テンプレートを表すボックスをクリックします。HTTP テンプレートの場合、パラメータは次のようになります。
モニターを起動するときに、次のステップでこれらのパラメータを定義する必要があります。
モニターの起動
17 ページの「新しいテスト エージェントの作成と展開」セクションで定義および展開したテスト エージェントを使用して、以下に示すようにテンプレート「HTTP」からモニターを開始できます。
各パラメータについて、属性を指定する必要があります。キーは、コントロール センターのパラメータの変数名と同じです。変数名は次のようにして調べることができます。
- サイドバーの「監視」をクリックし、「新しいモニター」を選択します。
- [マイテンプレート]をクリックします。
- 関心のあるテンプレートの下にある「編集」リンクをクリックします。
- 右上隅にある入力の編集ボタンをクリックします。
私たちの元ampデフォルトでは、変数名はコントロールセンターに表示される表示名の小文字バージョン（「url」対「URLただし、コントロール センターの GUI では、変数の名前を任意の名前に変更できます。
キーの他に、各パラメータにはその型を指定する必要があります。例:ampル、のために URLパラメータ タイプに関する完全な情報は、YANG モデルで確認できます。テスト エージェント インターフェイスの場合、以下のコードに示すように、タイプはより複雑な構造になっています。
元ampこれに続く場合、モニターにアラームは関連付けられていません。例:ampアラームに関連するファイルについては、62 ページの「アラームによるモニターの起動」のセクションに進んでください。
アラームによるモニターの起動
アラームをモニターに関連付けるには、定義済みのアラームテンプレートを指定するか、モニターの作成時にアラーム設定全体を指定します。1つの例を示します。ampそれぞれのアプローチの詳細は以下の通りです。
アラームテンプレートを指定してモニターアラームを設定する
アラーム テンプレートを使用するには、その ID を知っておく必要があります。そのためには、まず 39 ページの「すべてのアラーム テンプレートの取得」のセクションの説明に従ってすべてのアラーム テンプレートを取得し、関連するテンプレートの名前を書き留めます。その後、次のようにしてそのテンプレートを参照できます。
直接設定によるモニターアラームの設定y
あるいは、アラームテンプレートを参照せずに、モニターを作成するときにその構成全体を指定して、モニターのアラームを設定することもできます。これは、次の例に示すように行われます。ampル。
実行中のモニターの取得
現在実行中のすべてのモニターを取得するには、次のスクリプトを実行します。
manager.connect(host=args.host, port=args.port, username=args.user name, password=args.password, hostkey_verify=False) を m として実行します:
出力は、以下に示すように、実行中のすべてのモニターのリストです。
モニターの SLA ステータスの取得
モニターのSLAステータスを取得する方法は次のとおりです。この例ではampたとえば、過去 15 分、過去 24 時間、過去 XNUMX 時間という XNUMX つの時間間隔で、モニター「ネットワーク品質」の SLA ステータスを取得しています。
出力は次のようになります。
NETCONF 通知
モニターの NETCONF 通知は、SLA 違反によってトリガーされます。これは、モニターの SLA が、指定された時間枠 (デフォルトでは過去 15 分) 内に SLA しきい値 (「良好」または「許容可能」) を下回った場合に発生します。サービスが問題の影響を受けた後、SLA 違反通知はすぐに表示されますが、SLA ステータスは 15 分後にのみ「良好」に戻り、さらに違反が発生しない場合のみに注意してください。
時間枠は、SLA_STATUS_WINDOW（秒単位の値）の設定を編集することで変更できます。 /etc/netrounds/netrounds.conf.
モニターテンプレートのエクスポートとインポート
これは、テスト テンプレートの場合とまったく同じ方法で実行されます。52 ページの「テスト テンプレートのエクスポートとインポート」セクションと比較してください。以下のコード スニペットは、モニターのテンプレートをエクスポートおよびインポートする方法を示しています。
モニターテンプレートのエクスポート
モニターテンプレートのインポート
Tags Paragon Active Assurance で定義されているものは以下に適用できます。
- モニター
- モニターテンプレート
- テストエージェント
- TWAMP 反射板
- ホストにpingを実行します。
例えばampええ、できます tag 同じモニター tag モニターを実行するテスト エージェントのサブセットとして。この機能は、多数のモニターとテンプレートが定義されている場合に特に役立ちます。
モニターにSNMPトラップでアラームを設定した場合、SNMPトラップには同じものが割り当てられます。 tags モニターがある場合は、そのモニターとして。
作成 Tags
以下に作成方法を示します tag XMLで定義された名前と色tag> サブ構造。
割り当て Tag
を割り当てるには tag リソースに追加するには、新しいtag> 要素の下tags> そのリソースの要素。
割り当て方法は次のとおりです tag テストエージェントへ:
を割り当てるには tag TWにAMP リフレクターの場合は、次の操作を行います。
割り当て tag モニターへの接続も同様に処理されます。
または、既存の tag これらのリソースタイプのいずれかにリソースを作成するときに、tags> 要素を含む tag 問題です。
更新中 Tag
既存の tag 新しい属性を持つものは、 tag:
割り当て解除 Tag
割り当てを解除するには tag リソースから削除するには、属性nc:operation=”delete”をtag> リソースに属する要素。以下では、 tag モニターから。
削除する Tag
削除するには tag コントロールセンターから完全に削除するには、属性nc:operation=”delete”が再び使用されますが、今回は tag それ自体は、 。
トラブルシューティング
問題: Orchestrator と Paragon Active Assurance が同期していない
オーケストレーターとParagon Active Assuranceは、例えば次のような理由で同期が取れなくなる可能性があります。ampコントロール センター GUI で構成の変更が行われた場合、または構成の適用が成功せず、以前の状態へのロールバックに失敗した場合に表示されます。
ロールバックに失敗した場合、NETCONF サーバーは設定の変更を受け入れなくなり、同期が回復するまで設定がロックされていることを示すエラー メッセージが返されます。同期を回復して設定の変更をロック解除するには、すべての設定をコントロール センターから設定データベースに同期するコマンド rpc sync-from-ncc を実行する必要があります。
注記： の メール: すべてを正常に同期するには、ユーザー（または設定されたもの）にスーパーユーザー権限が必要です。これは、ncc user-updateコマンドで実現できます。 メール: –is-superuser ユーザーがスーパーユーザーでない場合は、すべてを同期できたわけではないが、処理できるものはすべて同期されたという警告が表示されます。
注記： オーケストレーターも構成を保存している場合は、要求された構成 (オーケストレーターがコントロール センターに期待する構成) が適用されていないため、構成も再同期する必要があります。
問題: サポートされていないリソースが原因で初期同期 (sync-from-ncc) が失敗しました
コントロール センター GUI で構成が作成されたアカウントで rpc sync-from-ncc を実行しようとすると、アカウントにサポートされていないリソースが含まれている場合に問題が発生する可能性があります。空のアカウントから開始し、すべての構成を NETCONF を通じて実行することをお勧めします。そうしないと、リソースの競合の問題が発生した場合、競合するリソースをアカウントから削除する必要があります。
問題: NETCONF コマンドが ncclient.operations.rpc.RPCError: アプリケーション通信エラーで失敗する
コントロール センターを再起動しても、NETCONF サーバーはコントロール センター サーバーへの接続を自動的に復元しません。コントロール センターへの接続を復元するには、NETCONF プロセスを再起動します: sudo systemctl restart netrounds-confd
テスト エージェント アプリケーションとテスト エージェント アプライアンスに関する注意事項
ConfD のテスト エージェント アプリケーション
テスト エージェントのうち、(新しい) テスト エージェント アプリケーションは、(古い) テスト エージェント アプライアンスとは少し異なる動作をします。
テストエージェントアプリケーションは現在、インターフェース構成をサポートしていません。そのため、YANGスキーマでは、このようなテストエージェントに対して空のインターフェース構成を指定できます。例については、23ページの「この文章」を参照してください。ampル。
sync-from-ncc コマンドを使用して ConfD データベースをコントロール センターと同期する場合、インターフェイス構成を空のままにして、コントロール センターで見つかった内容で上書きされないようにする必要があります。そのため、テスト エージェント アプリケーションを操作するときは、そのコマンドで特別なフラグ –without_interface_config を使用する必要があります。
テスト エージェント アプライアンスの空のインターフェイス構成
前述のように、テスト エージェント アプリケーションはインターフェイス構成をサポートしていないため、YANG スキーマでインターフェイスを省略できます。
しかし、テストエージェントアプライアンスからインターフェース構成を省略したいユースケースもあります。ampこの例としては、cloud-init を使用してテスト エージェントを起動し、テスト エージェントがオンラインになったときに ConfD で上書きするのではなく、そこからインターフェイス構成を使用するオーケストレーション シナリオが考えられます。
未定義のインターフェースに関する YANG スキーマの変更
空のインターフェース構成が許可されるようになったため (バージョン 2.34.0 以降)、テストまたはモニターの一部として実行されるタスクへの入力として任意のインターフェース名を指定できるようになりました。
これは、テスト エージェント アプリケーションを使用するために必要です。テスト エージェント アプリケーションの場合、ConfD でインターフェイス名が定義されていないためです。ただし、これは、存在しないインターフェイスを使用するようにテストまたはモニターを誤って構成した場合に、問題が発生する可能性があることも意味します。この点に注意してください。
ConfD で作成されたテストエージェントを登録する際の制限
REST または NETCONF/YANG API 経由でテスト エージェントを作成する場合、そのタイプがテスト エージェント アプライアンスかテスト エージェント アプリケーションかは事前にわかりません。これは、テスト エージェントが登録された後にのみ明らかになります。
テスト エージェントが登録され、これらの具体的なタイプのいずれかに変わったら、別のタイプのテスト エージェントとして再登録することはできません。つまり、最初にテスト エージェント アプライアンスとして登録し、次にテスト エージェント アプリケーションとして再登録することはできません。その逆も同様です。別のタイプのテスト エージェントが必要な場合は、新しいテスト エージェントを作成する必要があります。
付録: 完全な YANG モデルのツリー構造
この付録の 81 ページの「凡例」セクションでは、pyang -f tree コマンドで生成される YANG モデル ツリー構造の構文について説明します。
82 ページの「YANG モデル ツリー構造」のセクションでは、netrounds-ncc.yang に適用されたコマンドの出力を示します。この出力の一部は、ドキュメントの他の場所に再現されています。
伝説
YANGモデルのツリー構造
Juniper Networks、Juniper Networks ロゴ、Juniper、および Junos は、米国およびその他の国における Juniper Networks, Inc. の登録商標です。その他すべての商標、サービス マーク、登録商標、または登録サービス マークは、それぞれの所有者に帰属します。Juniper Networks は、本書の不正確な記載について一切責任を負いません。Juniper Networks は、予告なく本書を変更、修正、譲渡、または改訂する権利を留保します。Copyright © 2023 Juniper Networks, Inc. 無断複写・転載を禁じます。
ドキュメント / リソース
 |
Juniper NETWORKS NETCONF & YANG API ソフトウェア [pdf] ユーザーガイド NETCONF YANG API ソフトウェア、YANG API ソフトウェア、API ソフトウェア、ソフトウェア |