Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

グリビ

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

gRIBIサービスは、デバイスのルーティング情報ベース(RIB、ルーティングテーブルとも呼ばれます)内のルーティングエントリを追加、変更、および削除するためのAPIです。エントリが転送対象である場合、オペレーティング システムはデバイスの転送情報ベース(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 にあるプロトタイプ定義ファイルにあります。

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 つのポリシーを設定します。

    この例では、 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 つのポリシーを設定します。

    この例では、 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- ネクストホップグループをプログラムします。

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

ルート確認応答

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

Junosデバイスでは、メッセージAFTOperationentryフィールドに以下の値がサポートされています。

手記:

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

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

IPv4ルートのプログラム

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

  • トラフィック エンジニアリング VRF インスタンス: g_b4_cos1
  • [ network_instance ] フィールドを次のように設定します。 g_b4_cos1

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

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

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 メッセージに以下のフィールドを設定します。

複数クライアントのアービトレーション

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

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

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

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

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

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

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

ALL_PRIMARY冗長モードの場合:

  • すべてのクライアントがルートを変更できます。

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

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

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

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

手記:

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

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

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

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 を使用して、すべてのルートがサーバーのルーティング テーブルに正しく追加されたことを確認します。RPC Get() は、サーバーにインストールされているルートが正しいかどうかを定期的にチェックし、相違点を調整する場合にも役立ちます。

RPC Get() は、サーバーにインストールされている 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 インスタンスからルートをフラッシュします。

変更履歴テーブル

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

解放
形容
変更完了