Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページの内容
 

gRIBI

gRPCルーティング情報ベースインターフェイス(gRIBI)は、外部アプリケーションがネットワークデバイス上のルートをプログラム的に追加、変更、削除できるようにするgRPCサービスです。

gRIBIサービスは、デバイスのルーティング情報ベース(RIB、ルーティングテーブルとも呼ばれます)内のルーティングエントリーを追加、変更、削除するためのルーティングテーブルです。エントリーが転送の対象となる場合、オペレーティングシステムは自動的にデバイスの転送情報ベース(FIB、転送テーブルとも呼ばれます)に転送テーブルを追加します。gRIBIクライアントアプリケーションは、ジュニパー Juniper Extension Toolkit(JET)でサポートされているどの言語でも使用できます。クライアントアプリケーションは、外部ネットワーク管理システム上で実行することも、ネットワークデバイス上のローカルアプリケーションとして実行することもできます。

gRIBIサービスのプロト定義ファイルは 、https://github.com/openconfig/gribi/blob/master/v1/proto/service/gribi.proto にあります。JunosデバイスでサポートされているgRIBIメッセージは、 JET IDLパッケージに含まれています。

OpenConfig抽象転送テーブル(AFT)モデルは、ネットワークデバイスにインストールされている転送エントリーを記述するYANGデータモデルです。gRIBIは、OpenConfig AFTモデルのプロトコルバッファ変換バージョンを使用して、変更可能なRIBエントリを記述します。OpenConfig AFT スキーマの protobuf 表現は、 https://github.com/openconfig/gribi/blob/master/v1/proto/gribi_aft/gribi_aft.proto にある proto 定義ファイルにあります。

gRIBIのメリット:

  • ルートをプログラムするときに確認を送信します。
  • 階層ルックアップをサポートします。
  • 複数のクライアントがgRIBIセッションに接続されている場合のアービトレーションをサポートします。

show route extensiveコマンドを使用して、クライアントIDとルートで使用されるネクストホップグループIDを含むgRIBIのルートデータを表示します。

注:

特に同じルートセットの場合、両方を同時に使用せず、gRIBIまたはJET RIBサービスAPIのいずれかを使用することをお勧めします。

サポートされているRPC

Junosデバイスは、gRIBIサービスRPCをサポートしており、デバイスのRIBからルートをリモートで取得、追加、変更、または削除することができます。RPCは、デバイス上の抽象転送テーブル(AFT)を変更または読み取ることによって機能します。

表1:サポートされているgribi.proto RPC
RPC 定義 リリースで導入
Modify()

AFTからエントリを追加、変更、または削除します。

Junos OSリリース19.4R1

Junos OS Evolvedリリース20.3R1
Get()

AFTからインストールされているエントリを取得します。

Junos OS Evolved 22.2R1
Flush()

FlushRequestメッセージに記載されている内容に一致するデバイスのAFTエントリをすべて削除します。

Junos OS Evolved 22.2R1

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

Junos OS Evolvedリリース23.4R1以降

始める前に:

gRIBI用にネットワークデバイスを設定するには:

  1. フィルターベースの転送を使用してルーティングインスタンスを作成します。
  2. 2 つのポリシーを設定します。1 つはマルチパス解決を処理し、もう 1 つはロードバランシングを処理します。

    この例では、 mp-resolve というポリシーが解決マルチパス処理します。解決ルートに複数のパスがある場合、解決したルートはすべてのパスで解決されます。ポリシー pplb は、各パケットのトラフィックの負荷分散をパケット転送エンジンに指示します。

  3. 残りの保留時間を設定して、システムがルートを更新するのに十分な時間を与えます。システム再起動後、rpd プロセスは、残りの保留時間が終了するまで待ってから、ルートをクリーンアップします。rpdプロセスは、待機時間が終了する前に更新されたルートを削除しません。

    これで、gRIBIサービスRPCを使用する準備が整いました。

Junos OS Evolvedリリース23.4R1以前

始める前に:

gRIBI用にネットワークデバイスを設定するには:

  1. フィルターベースの転送を使用してルーティングインスタンスを作成します。
  2. ルーティングインスタンスでデフォルト、IPv4ファミリープロトコル、およびIPv6ファミリープロトコルのルート解決に使用するルーティングテーブルを設定します。

    各プロトコルファミリーに最大2つのルーティングテーブルを指定できます。ルート解決スキームは、最初のルーティングテーブルでプロトコルネクストホップアドレスのエントリーが見つからない場合にのみ、2番目のルーティングテーブルをチェックします。

    この例では、 teVRF.inet.0 がデフォルトのルーティングテーブルです。そのルーティングテーブルにネクストホップアドレスのルートがない場合、ルートソリューションスキームは inet.3 テーブルをチェックします。

  3. IPv4 および IPv6 ファミリー解決ツリーのインポートポリシーを指定します。

    次に例を示します。

  4. 2 つのポリシーを設定します。1 つはマルチパス解決を処理し、もう 1 つはロードバランシングを処理します。

    この例では、 mp-resolve というポリシーが解決マルチパス処理します。解決ルートに複数のパスがある場合、解決したルートはすべてのパスで解決されます。ポリシー pplb は、各パケットのトラフィックの負荷分散をパケット転送エンジンに指示します。

  5. 転送プレーンにネクストホップをインストールする際にネクストホップ階層を保持するようにルーティングオプションを設定します。
  6. IPv4およびIPv6ファミリープロトコルのルート解決に使用するルーティングテーブルと、ルーティングオプションレベルでルート解決のポリシーを設定します。ルーティングインスタンスレベルで設定した各ルーティングテーブルに対して、この設定を繰り返します。

    次に例を示します。

  7. 残りの保留時間を設定して、システムがルートを更新するのに十分な時間を与えます。システム再起動後、rpd プロセスは、残りの保留時間が終了するまで待ってから、ルートをクリーンアップします。rpdプロセスは、待機時間が終了する前に更新されたルートを削除しません。

    これで、gRIBIサービスRPCを使用する準備が整いました。

ルートの変更

Modify() RPCを使用して、新しいルートをインストールし、gRIBIサーバーのRIB内の既存のルートを編集します。ルートはスタティックルートとして追加されます。

Modify()は双方向ストリーミングRPCです。クライアントは、サーバー上のAFTエントリを変更するためのModifyRequestメッセージを含むModify()RPCを送信します。各ModifyRequestについて、gRIBIサーバーはModifyResponseメッセージでクライアントに応答します。

ModifyRequestメッセージは、1つ以上のAFTOperationメッセージで構成されます。各AFTOperationメッセージは、1つのAFTエントリーの追加、変更、または削除のリクエストを定義します。gRIBIサーバーは、Modify()RPCがストリーミングする順序でAFT操作を処理します。

Junosデバイスは、以下のAFTエントリータイプをサポートしています。

  • IPv4Entry—IPv4ルートをプログラムします。
  • NextHopEntry—ネクストホップをプログラムします。
  • NextHopGroup—ネクストホップグループをプログラムします。

Modify() RPCを使用して、以下の機能を実行します。

ルート確認応答

Modify() RPCを使用してパケット転送エンジン内のルートを正常にプログラムすると、サーバーは確認応答を送信します。gRIBI APIが指定されたタイムアウト時間内にパケット転送エンジンのルートをプログラムできない場合、サーバーはエラーメッセージを送信します。このタイムアウトの長さを設定できます。確認応答は、最新のルートに対してのみ有効です。古いルートが確認応答を送信し、新しいルートが送信しない場合、パケット転送エンジンはそれをエラーとして記録します。

Junosデバイスは、メッセージAFTOperationのentryフィールドで以下の値をサポートしています。

注:

Junosデバイスは MAC_ENTRY オプションをサポートしていません。

show route extensiveコマンドを使用して、確認応答ステータスを表示します。確認応答ステータスは、rpdプロセスの再起動後も永続的です。

IPv4ルートのプログラム

IPv4ルートをプログラムするには、IPv4EntryAFTエントリを使用します。AFTは、宛先アドレスに基づいて入力パケットを照合し、対応するネクストホップにマッピングします。ネットワーク内のデフォルトのVRFインスタンスとトラフィック制御VRFインスタンスにAFTエントリをインストールします。デフォルト以外のインスタンスにAFTエントリをインストールするには、AFTOperationメッセージのnetwork_instanceフィールドにVRFインスタンスを指定します。次に例を示します。

  • トラフィック制御VRFインスタンス: g_b4_cos1
  • network_instanceフィールドを次のように設定します。g_b4_cos1

gRIBIクライアントは、サーバーが関連するNextHopGroupおよびNextHopメッセージを受信したという確認をサーバーから受信した後にのみ、サーバー上のIPv4EntryAFTエントリーをプログラムします。クライアントがNextHopGroupメッセージを確認せずにサーバー上のIPv4EntryAFTエントリをプログラムすると、そのルートを非表示ルートとしてサーバーに追加します。

プログラムネクストホップとネクストホップグループ

gRIBI Modify() RPCを使用して、gRIBIサーバー上のネクストホップまたはネクストホップグループをプログラムします。RPCは、デフォルトのVRFインスタンス内にのみネクストホップとネクストホップグループを作成します。

同じ ModifyRequest メッセージにネクストホップとネクストホップグループが存在する場合、gRIBIクライアントはAFT動作に従ってそれらを処理します。AFT操作で NextHop エントリーと NextHopGroup エントリーが追加された場合、クライアントはネクストホップグループを追加する前に、すべてのネクストホップをサーバーに追加します。AFT操作が NextHop エントリーと NextHopGroup エントリーを削除した場合、クライアントは逆の順序で処理します。ネクストホップを削除する前に、すべてのネクストホップグループを削除します。

Junosデバイスでは、RPCはinet6.3テーブル内のネクストホップをFC01::next_hop_idとしてインスタンス化します。ネクストホップIDは16進数です。例えば、ネクストホップIDが10の場合、サーバーはinet6.3テーブルにFC01::Aと呼ばれるルートをインストールします。

ネクストホップグループは、inet6.3テーブルにFC02::next_hop_idとして表示されます。例えば、ネクストホップグループIDが100の場合、サーバーはinet6.3テーブルにFC02::64と呼ばれるルートをインストールします。

例えば、直接到達可能なインターフェイスを介してネクストホップオブジェクトをプログラムするには、以下を行います。

  1. アドレス 10.0.1.2 がインターフェイス et-0/0/7.0 経由で到達可能であると仮定して、 Afts メッセージに以下のフィールドを設定します。ここで、= はフィールドをその値に設定することを意味します。

  2. AFTOperationメッセージフィールドを次のように設定します。

  3. 上記で定義したAFTOperationを使用するようにModifyRequestメッセージを設定します。

  4. 上記のModifyRequestメッセージを使用してModify()RPCに呼び出します。

  5. ルートが正常にプログラムされたことを確認するには、CLIで show route programmed コマンドを使用します。

MACアドレスを使用したプログラムネクストホップ

オプションで、IP アドレスではなく MACアドレスでネクストホップを識別することもできます。この機能は、デバイスが動的アドレス解決プロトコル(ARP)または近隣探索プロトコル(NDP)を使用してネクストホップのMACアドレスを検索できないネットワークで有効です。MACアドレスを使用するには、AFTメッセージのip_addressフィールドではなくmac_addressフィールドを使用します。

注:このインターフェイスを使用するすべてのトラフィックは、gRIBIサービスによってプログラムされていないルート上のトラフィックであっても、gRIBIサービスによってプログラムされた静的MACアドレスを使用します。

gRIBIサービスを使用してインターフェイス上のネクストホップとしてMACアドレスをプログラムした後、デバイスはこのインターフェイスを使用するいかなるトラフィックに対してもダイナミックARPまたはNDPを使用しません。クライアントの切断時にプログラムされたgRIBIネクストホップが削除またはパージされた場合、デバイスは自動的にインターフェイス上のARPを再度有効にし、ルートはダイナミックARPを使用して機能し続けます。

例えば、直接到達可能なインターフェイスを介して、MACアドレスを持つネクストホップオブジェクトをプログラムするには:

  1. ネクストホップでプログラミングするインターフェイスが番号付きインターフェイスであることを確認します。

  2. インターフェイスでIPv6ファミリーが有効になっていることを確認します。

  3. MACアドレス 00:00:5E:00:53:00 がインターフェイス et-0/0/7.0 経由で到達可能であると仮定して、 Afts メッセージに以下のフィールドを設定します。ここで、= はフィールドをその値に設定することを意味します。

  4. AFTOperationメッセージフィールドを次のように設定します。

  5. 上記で定義したAFTOperationを使用するようにModifyRequestメッセージを設定します。

  6. 上記のModifyRequestメッセージを使ってModify()RPCに電話をかけます。

  7. ルートが正常にプログラムされたことを確認するには、CLIの show route programmed コマンドを使用します。

階層ルックアップとIP-in-IPトンネリング

gRIBIのJunos実装は、階層ルックアップをサポートしています。階層ルックアップを設定するには、IPv4 AFTを使用してIP-IPトンネルエンドポイントとサイトグループの仮想IPアドレスルートをプログラムします。

IP-in-IP トンネルのイングレスノード上のトラフィックをカプセル化するには、 NextHop メッセージに以下のフィールドを設定します。

複数のクライアントの仲裁

Modify() RPCは、複数のクライアントがgRIBIサーバーに接続されている場合のアービトレーションをサポートします。仲裁では、どのクライアントがどの操作を実行できるかが決定されます。

SessionParametersメッセージを使用して、gRIBIクライアントの永続モードとクライアント冗長性モードを設定します。すべてのクライアントが、SessionParameters メッセージのすべての属性の同じ値を送信する必要があります。SessionParametersは、セッションの存続期間中に 1 回だけ送信する必要があります。

SessionParameters 再接続後に送信される最初のメッセージである必要があります。クライアントが再接続すると、新しいセッションが開始されます。他のクライアントがすでに接続されている場合は、 SessionParameters メッセージ値を既存のクライアントが設定した値と一致させます。すべてのクライアントが再接続した場合、 SessionParameters メッセージ値を前のセッションで使用した値とは異なる値に設定できます。

Junosデバイスは、 PRESERVE と DELETE の両方の永続モードをサポートしています。永続モードが PRESERVEに設定されている場合、クライアントが切断された後も、サーバーはクライアントによって追加されたAFTエントリを保持します。永続モードが DELETE に設定されている場合、クライアントの切断時にサーバーは AFT エントリを削除します。

セッションパラメーターを変更する前に、すべてのルートを削除することをお勧めします。他のモードでルートを追加した後に、セッションパラメーターを変更し、冗長性モードを ALL_PRIMARY と SINGLE_PRIMARY に切り替えると、予期しない動作が発生する可能性があります。

クライアントが複数存在する場合は、次の2つのクライアント冗長性モードのいずれかを選択する必要があります。

すべてのプライマリモード

ALL_PRIMARY冗長性モードでは:

  • どのクライアントでもルートを変更できます。

  • 複数のクライアントが同じAFTエントリを追加できます。

  • gRIBI APIは、どのクライアントがルートを追加したかのマッピングを維持します。

  • 最初の追加操作では、エントリーが RIB に追加されます。その後、別のクライアントからの同じエントリーに対する追加操作を行うと、そのエントリーを参照するクライアントのリストにクライアントが追加されます。

  • 削除操作は、エントリを参照するクライアントのリストからクライアントを削除します。エントリーは、エントリーを参照するクライアントがない場合にのみ削除されます。

注:

FlushRequestが処理されると、参照カウントチェックなしでエントリーが削除されます。

show route extensiveコマンドを使用して、ルートの詳細を表示します。ALL_PRIMARYモードでshow route extensiveコマンドが表示される内容の例を次に示します。わかりやすくするために出力が短縮されています。

シングルプライマリモード

SINGLE_PRIMARY冗長性モードでは:

  • gRIBIクライアントには、プライマリ(アクティブ)またはバックアップのロールがあります。

  • AFT操作を実行できるのはプライマリクライアントだけです。

  • 選択IDが最も高いクライアントがプライマリクライアントです。それ以外のクライアントはすべてバックアップクライアントです。

  • バックアップクライアントがプライマリクライアントになると、以前のプライマリクライアントで追加されたルートを新しいプライマリクライアントで変更できます。

各デバイスの選択IDを設定して、どのクライアントがプライマリクライアントであるかを決定します。選挙IDは、冗長性モードでのみ設定 SINGLE_PRIMARY できます。選択IDは、クライアントがダウン状態であっても保持されます。プライマリクライアントが切断された場合でも、別のデバイスの選択IDをより高い位置に設定するまで、プライマリクライアントのままとなります。選択IDが設定された後、新しいプライマリクライアントはgRIBIエントリーのプログラミングを続行します。

選挙IDを更新するには、選挙IDを新しい値に設定して ModifyRequest メッセージを送信します。各クライアントは、一意の選挙IDを持っている必要があります。選挙IDを更新する際に、 ModifyRequest メッセージの他のフィールドを設定しないでください。

選挙IDは、以下のメッセージに存在します。

  • ModifyRequest—クライアントの選択IDを設定します。選択IDが最も高いクライアントがプライマリクライアントになります。

  • AFTOperation—サーバーがAFT操作を処理する必要があるかどうかを決定します。

  • ModifyResponse—サーバーは、現在最も高い選択IDで応答します。

show programmable-rpd clients detail コマンドを使用して、グループ ID と、クライアントがプライマリ ロールまたはバックアップ ロールを持っているかどうかを表示します。

show route extensiveコマンドを使用して、ルートの詳細を表示します。show route extensive コマンドが SINGLE_PRIMARY モードで表示される内容の例を次に示します。わかりやすくするために出力が短縮されています。

VRFインスタンスでのフォールバックルートのプログラム

ネクストホップが静的ルートを介して到達できなくなった場合、ネットワークはトラフィックの中断を回避するために、代替ルートを介してトラフィックを再ルーティングできます。この代替ルートはフォールバック ルートと呼ばれます。トラフィックがトンネルにカプセル化されていない場合は、通常 CLI を使用する場合と同様にフォールバック静的ルートを設定します。ただし、トラフィックがトンネルにカプセル化されている場合は、gRIBIを使用して、カプセル化解除とカプセル化を含むフォールバックトンネルをプログラムできます。

VRFでフォールバックルートをプログラムすることで、システムが古いトンネルからのトラフィックをカプセル化解除し、新しいトンネルで再カプセル化してから、トラフィックをネクストホップに再ルーティングするようにすることができます。この機能は、IPv4 または IPv6 ペイロードを持つ動的 IP-IP トンネルの IPv4 トランスポートをサポートします。

カプセル化解除および再カプセル化機能を備えたフォールバックIP-in-IPトンネルをプログラムするには、 NextHop メッセージに以下のフィールドを設定します。

トラフィック制御仮想ルーティングおよび転送(VRF)インスタンスのデフォルトルートをバックアップルートとして使用できます。VRF で設定する将来のルートがフォールバック ルートとして使用されるように、最初にデフォルト ルートを VRF に追加します。このデフォルトルートを使用するには、 decapsulate_header フィールドを OPENCONFIGAFTTYPESENCAPSULATION HEADERTYPE_IPV4 に設定し、 network_instance を DEFAULTに設定します。このデフォルトルートには、カプセル化解除されたネクストホップがあり、デフォルトVRFでルートを検索します。

また、バックアップネクストホップグループを選択して、フォールバックルートを簡単に設定することもできます。そのためには、NextHopGroupメッセージにbackup_next_hop_groupフィールドを設定します。

VRFインスタンスの選択

gRIBIは、デフォルト以外のVRFインスタンスでのルートのプログラミングをサポートしていません。デフォルト以外のVRFインスタンスを使用するには、まずCLIを使用してファイアウォールフィルターを設定します。ファイアウォールフィルターは、必要なDSCPとIPプロトコルと一致する必要があります。トラフィックが予想されるインターフェイスにフィルターを適用します。

例えば、トラフィックがインターフェイスet-0/0/0上にある場合:

ポリシーベースのフォワーディング

PolicyForwardingEntryメッセージを使用して、gRIBIサーバー上のポリシーベースの転送をプログラムします。ポリシーベースの転送により、バックアップトンネルに移動されたトラフィックは、ルーティングテーブルの内容に関係なく、トンネル内にとどまります。

一致条件を設定し、トラフィックを転送するポリシーをプログラムするには:

  1. Aftsメッセージに以下のフィールドを設定します。

  2. AFTOperationメッセージに以下のフィールドを設定します。

  3. 上記で定義したAFTOperationを使用するようにModifyRequestメッセージを設定します。

  4. 上記のModifyRequestメッセージをModify() RPCに呼び出します。

ルートを取得

クライアントがgRIBIサーバーへの接続を失うと、ダウンタイム中にプログラムされたルートがサーバーに追加されない可能性があります。サーバーへの接続が復旧したら、 Get() RPC を使用して、すべてのルートがサーバーのルーティングテーブルに正しく追加されたことを確認します。 Get() RPCは、サーバーにインストールされているルートが正しいことを定期的にチェックし、違いを調整するのにも便利です。

Get() RPCは、サーバーにインストールされているAFTのコンテンツを取得します。クライアントが Get() RPC 要求を送信すると、サーバーは GetResponse ストリームを使用して、現在インストールされているエントリーのセットで応答します。サーバーは、確認されたエントリーのみで応答します。サーバーがすべてのエントリーをクライアントに送信した後、サーバーはRPCを閉じます。

グレースフルルーティングエンジンスイッチオーバー(GRES)が設定されている場合、gRIBIサーバーとrpdプロセスもgRIBIサーバーの再起動後にルートを回復します。クライアントがサーバーに再接続すると、クライアントは自動的にgRIBI Get() RPCリクエストをサーバーに送信します。GRES が設定されている場合、クライアントはサーバー上のルートを調整します。クライアントが別の Get() RPCリクエストを送信した場合、 GetResponse ストリームにはサーバー上のアクティブな調整済みルートが含まれます。GRES が設定されていて、ノンストップ ルーティングが構成されていない場合、gRIBI API はルーティングエンジンのスイッチオーバー後のルートも回復します。

注:

rpdプロセスが再起動すると、アクティブなルートのみが復元されます。

ルートのフラッシュ

Flush() RPCは、FlushRequestメッセージに記述されているものに一致するサーバーのgRIBIプログラム済みルートをすべて削除します。FlushRequestメッセージを送信すると、gRIBIプログラムされたルートをサーバーからすばやく簡単に削除できます。

トラフィック制御VRFインスタンスにルートが存在する場合は、VRFインスタンスを削除する前に、 Flush() RPCを使用してVRFインスタンスからルートをフラッシュします。

変更履歴テーブル

サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がお使いのプラットフォームでサポートされているかどうかを確認します。

リリース
説明
23.4R1-EVO
gRIBIサービスRPCを実行するために、[edit routing-options resolution]階層レベルでステートメントを設定する必要がなくなりました。