Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

gNOI システム サービス

概要 gNOI System サービスを使用して、デバイスの再起動、ソフトウェアのアップグレード、ネットワークのトラブルシューティングなど、ターゲット ネットワーク デバイスでシステム操作を実行します。

概要

gNOI System サービスは、ネットワーク デバイス上でさまざまなシステム操作を実行する RPC を提供します。これには、以下の操作が含まれます。

  • デバイスを再起動する
  • ping および traceroute コマンドを実行してネットワークをトラブルシューティングする
  • ソフトウェアのアップグレード
  • ルーティング エンジンのスイッチオーバーを実行する

proto 定義ファイルは 、https://github.com/openconfig/gnoi/blob/master/system/system.proto にあります。

メモ:

gnoi-systemシステム障害が発生した場合、プロセスが再起動します。手動で再起動するには、 コマンドをrestart gnoi-system使用します。

ネットワーク デバイスの設定

開始する前に、以下を行います。

  • gRPCサービスの設定に関する説明に従って、ネットワークデバイス上で gRPCサービスを設定します
  • gNOI サービスの構成に関する説明に従って、gNOI 操作をサポートするようにネットワーク管理システムを構成します。

サービス RPC を使用するための追加設定は System 必要ありません。

Ping と Traceroute

ネットワーク デバイスで ping および traceroute コマンドを実行して、ネットワーク上の問題をトラブルシューティングできます。

表 1:ネットワークのトラブルシューティングに対応した system.proto RPC
リリースで導入された RPC の説明
Ping()

デバイスに Ping を送信します。RPC は Ping() IPv4 および IPv6 ping をサポートします。この RPC は、ping の完了後に ping の結果をストリーミングします。

デフォルトパケット数:5

Junos OS Evolved 22.2R1

Traceroute()

ターゲットデバイスで traceroute コマンドを実行し、結果をストリーミングバックします。

デフォルトホップカウント:30

Junos OS Evolved 22.2R1

例:Ping

この例では、クライアントは Python アプリケーションを gnoi_ping_request.py 実行します。アプリケーションは RPC を Ping() ネットワーク デバイスに送信し、ネットワーク上の指定されたデバイスに ping を送信します。

アプリケーションは gnoi_ping_request.py 、チャネルを grpc_channel 確立するためにモジュールをインポートします。このモジュールについては grpc_channel 、「 gNOI サービスの設定」を参照してください。アプリケーションの引数は 、gnoi_ping_request_args.txt ファイルに格納されます。ここには、アプリケーションと引数のファイルが表示されます。

gnoi_ping_request.py

gnoi_ping_request_args.txt

アプリケーションの実行

クライアントでアプリケーションを実行し、RPC 呼び出し認証情報に対してサーバーのパスワードを要求します。は PingResponse 、デバイスが 5 つの ping を送信したことを示しています。最後の応答には ping リクエストの要約統計が含まれており、デバイスが 5 つの ping を送信し、5 つの応答を受信したことを示しています。

デバイスを再起動する

サービス RPC を System 使用して、デバイスをリモートで再起動し、再起動のステータスを確認し、必要に応じて再起動をキャンセルします。これらの RPC は、デバイス上または特定のサブコンポーネント上で実行できます。Junos デバイスは、以下の再起動方法をサポートします。

  • COLD(1):すべてのタイプの再起動で使用可能。

  • POWERDOWN(2):FPC の再起動に使用します。

  • HALT(3):アクティブな制御プロセッサの再起動に使用します。

  • POWERUP(7):FPC の再起動に使用します。

表 2:再起動用にサポートされている system.proto RPC
リリースで導入された RPC の説明
Reboot()

ターゲットを再起動します。ターゲットに対して一度に 1 回だけ再起動要求を実行できます。

オプションで、将来の再起動に遅延を設定し、サブコンポーネントを個別に再起動し、再起動の開始時にメッセージを追加することができます。遅延はナノ秒単位で設定されます。

Junos デバイスは、以下の再起動方法をサポートします。

  • コールド(1)

  • パワーダウン(2)

  • 停止(3)

  • 電源投入(7)

Junos OS Evolved 22.2R1

RebootStatus() 再起動のステータスを返します。

Junos OS Evolved 22.2R1

CancelReboot() 保留中の再起動要求をキャンセルします。

Junos OS Evolved 22.2R1

例:再起動

この例では、クライアントは Python アプリケーションを gnoi_reboot_request.py 実行します。アプリケーションは再起動要求を送信し、再起動のステータスを確認します。

アプリケーションにより、ユーザーは再起動の遅延を秒単位で設定できます。 RebootRequest() はナノ秒単位で遅延を解釈するため、アプリケーションはユーザー入力をナノ秒に変換します。この例では、クライアントは再起動操作の 60 秒の遅延を指定します。

アプリケーションは gnoi_reboot_request.py 、チャネルを grpc_channel 確立するためにモジュールをインポートします。このモジュールについては grpc_channel 、「 gNOI サービスの設定」を参照してください。アプリケーションの引数は 、reboot_status_request_args.txt ファイルに格納されます。ここには、アプリケーションと引数のファイルが表示されます。

gnoi_reboot_status_request.py

reboot_status_request_args.txt

アプリケーションの実行

クライアントがアプリケーションを実行すると、アプリケーションは RPC 呼び出し認証情報に対してサーバーのパスワードを入力するよう求めます。アプリケーションは、60 秒の遅延後にサーバーを再起動し、該当する再起動ステータス メッセージを返します。下の reason メッセージ セットは、サーバーが再起動する直前にサーバーにも表示されます。この例では、サーバーにログインしたユーザーは、再起動する直前に「gNOI の再起動をテストする」と表示されます。

ソフトウェアのアップグレード

表 3 は、ソフトウェア アップグレードをサポートする system.proto RPC を示しています。

表 3:ソフトウェア アップグレードに対応した system.proto RPC
リリースで導入された RPC の説明
SetPackage()

ターゲット デバイスにソフトウェア イメージをインストールします。

Junos OS Evolved 22.2R1

RPC を SetPackage() 使用して、対象のデバイスにソフトウェア イメージをコピーしてインストールできます。ソース ソフトウェア イメージは、ローカル ネットワーク管理システム上に存在する必要があります。ファイルのコピー操作に成功し、ターゲット・ロケーションに同じ名前のファイルがすでに存在している場合は、ファイルが上書きされます。対象の場所が存在しない場合、またはデータの書き込みエラーが発生した場合、RPC はエラーを返します。

デフォルトでは、 SetPackage() デバイスは再起動されず、ソフトウェアはアクティブ化されません。新しいソフトウェアをアクティブにするには、 activate メッセージで SetPackageRequest オプションを 1 に明示的に設定する必要があります。ソフトウェアをアクティブにすると、デバイスが再起動し、新しいソフトウェア イメージが使用されます。ソフトウェアをアクティブ化しない場合は、関連ノードを再起動してインストールを完了し、新しいソフトウェア イメージをアクティブ化する必要があります。

例:ソフトウェア パッケージのインストール

この例では、クライアントは Python アプリケーションを gnoi_system_set_package.py 実行し、次の操作を実行します。

  • ソフトウェア パッケージをローカル ネットワーク管理システムからネットワーク デバイスにコピーします。
  • ネットワーク デバイスにパッケージをインストールします。
  • ネットワーク デバイスを再起動し、新しいソフトウェア イメージをアクティブ化します。

アプリケーションは、コピーおよびインストール操作の SetPackageRequest 要求を定義するために、適切なパラメーターを使用してメッセージを作成します。アプリケーションは、RPC を SetPackage() 呼び出して、ネットワーク デバイスに要求を送信します。 SetPackageRequest このメッセージには、以下のコンポーネントが含まれています。

  • ソフトウェア イメージのパスとファイル情報を含む最初 Package のメッセージ。 activate デバイスを再起動してソフトウェアをアクティブにするには、引数を1(True)に設定します。
  • 64 KB を超えない順次メッセージ内のソフトウェア・イメージ・ファイルのコンテンツのストリーム。
  • ファイルの内容の整合性を検証するためのファイル チェックサムを含む最後のメッセージ。

アプリケーションは gnoi_system_set_package.py 、チャネルを grpc_channel 確立するためにモジュールをインポートします。このモジュールについては grpc_channel 、「 gNOI サービスの設定」を参照してください。アプリケーションの引数は、ファイルに args_system_set_package.txt 格納されます。アプリケーション・ファイルと引数ファイルは以下のとおりです。

gnoi_system_set_package.py

args_system_set_package.txt

アプリケーションの実行

クライアントがアプリケーションを実行すると、アプリケーションはパッケージをローカル デバイスからネットワーク デバイスにコピーしてインストールし、デバイスを再起動してインストールを完了します。

ルーティング エンジンの切り替え

RPC を SwitchControlProcessor() 使用してルーティング エンジン のスイッチオーバーを実行できます。

メモ:

連続するルーティング エンジン スイッチオーバー イベントは、両方のルーティング エンジンが起動した後、最低 400 秒離れる必要があります。

表 4:ルーティング エンジン スイッチオーバーでサポートされている system.proto RPC
リリースで導入された RPC の説明
SwitchControlProcessor()

現在のルーティング エンジンから指定されたルーティング エンジンに切り替えます。現在のルーティング エンジンと指定されたルーティング エンジンが同じ場合、それは NOOP です。ターゲットが存在しない場合、RPC はエラーを返します。

メモ:

Junos デバイスは にSwitchControlProcessorResponse対応control_processor していません。

Junos OS Evolved 22.2R1

例:ルーティング エンジンのスイッチオーバー

この例では、gNOI クライアントがアプリケーションを gnoi_system_switch_control_processor.py 実行してルーティング エンジン スイッチオーバーを実行します。クライアントは、引数を含めることで、プライマリルーティングエンジンとなるスイッチ制御プロセッサ(ルーティングエンジン)を control_processor 指定します。ターゲットのルーティング エンジンが存在しない場合、RPC はエラーを INVALID_ARGUMENT 返します。

アプリケーションは、チャネルを grpc_channel 確立するためにモジュールをインポートします。このモジュールについては grpc_channel 、「 gNOI サービスの設定」を参照してください。

gnoi_system_switch_control_processor.py

アプリケーションの実行

クライアントはアプリケーションを実行し、re1 がプライマリ ルーティング エンジンになるように引数を にre1設定control_processorします。

操作を実行した後、re1 はターゲット デバイス上のプライマリ ルーティング エンジンです。