このページの目次
グリビ
概要 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)を変更または読み取ることで機能します。
リリースで導入された | RPC | 定義 |
---|---|---|
Modify() |
AFT のエントリを追加、変更、または削除します。 |
Junos OSリリース19.4R1 Junos OS Evolvedリリース20.3R1 |
Get() |
インストールされたエントリを AFT から取得します。 |
Junos OS Evolved 22.2R1 |
Flush() |
|
Junos OS Evolved 22.2R1 |
ネットワーク デバイスの設定
Junos OS Evolved リリース 23.4R1 およびそれ以降
Junos OS Evolvedリリース23.4R1以前
ルートの変更
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()
を使用して、次の機能を実行します。
- ルート確認応答
- IPv4ルートのプログラム
- ネクストホップとネクストホップグループのプログラム
- MACアドレスを持つプログラムネクストホップ
- 階層ルックアップとIP-in-IPトンネリング
- 複数クライアントのアービトレーション
- VRF インスタンスでのフォールバックルートのプログラム
- VRF インスタンスの選択
- ポリシーベース転送
ルート確認応答
Modify()
RPCを使用してパケット転送エンジンでルートを正常にプログラムすると、サーバーは確認応答を送信します。gRIBI APIが指定されたタイムアウト期間内にパケット転送エンジンでルートをプログラムできなかった場合、サーバーはエラーメッセージを送信します。このタイムアウトの長さは構成できます。確認応答は、最新のルートに対してのみ有効です。古いルートで確認応答が送信され、新しいルートで確認応答が送信されない場合、パケット転送エンジンはそれをエラーとして記録します。
Junosデバイスでは、メッセージAFTOperation
のentry
フィールドに以下の値がサポートされています。
AFTOperation { EntryAckType { INVALID; FIB_ACK; RIB_ACK; } ack_type; )
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
というルートをインストールします。
たとえば、直接到達可能なインターフェイスを介してネクストホップオブジェクトをプログラムするには、次のようにします。
-
アドレス10.0.1.2がインターフェイスet-0/0/7.0経由で到達可能であると仮定して、
Afts
メッセージで以下のフィールドを設定します。ここで、=はフィールドをその値に設定することを意味します。NextHop { ip_address = 10.0.1.2; // Next hop IP address InterfaceRef { interface = "et-0/0/7"; subinterface = 0; } } NextHopKey { index = 1; }
-
AFTOperation
メッセージフィールドを次のように設定します。AFTOperation { Operation { ADD; } entry { next_hop; // NextHopKey object created above } }
- 上記で定義した
AFTOperation
を使用するようにModifyRequest
メッセージを設定します。 -
上記の
ModifyRequest
メッセージを使用して、Modify()
RPC を呼び出します。 -
ルートが正常にプログラムされたことを確認するには、CLI で
show route programmed
コマンドを使用します。
MACアドレスを持つプログラムネクストホップ
オプションとして、IP アドレスではなく MAC アドレスでネクストホップを識別できます。この機能は、デバイスが動的アドレス解決プロトコル(ARP)または近隣探索プロトコル(NDP)を使用してネクストホップのMACアドレスを検索できないネットワークで役立ちます。MACアドレスを使用するには、AFTメッセージのip_address
フィールドではなくmac_address
フィールドを使用します。
gRIBI サービスを使用してインターフェイスのネクスト ホップとして MAC アドレスをプログラムした後、デバイスはこのインターフェイスを使用するトラフィックにダイナミック ARP または NDP を使用しません。クライアントが切断されたときに、プログラムされた gRIBI ネクストホップが削除またはパージされた場合、デバイスはインターフェイス上の ARP を自動的に再度有効にし、ルートはダイナミック ARP を使用して機能し続けます。
たとえば、直接到達可能なインターフェイスを介してMACアドレスを持つネクストホップオブジェクトをプログラムするには、次のようにします。
-
ネクスト ホップでプログラムするインターフェイスが番号付きインターフェイスであることを確認します。
-
インターフェイスで IPv6 ファミリーが有効になっていることを確認します。
-
MACアドレス00:00:5E:00:53:00がインターフェイスet-0/0/7.0経由で到達可能であると仮定して、
Afts
メッセージで以下のフィールドを設定します。ここで、=はフィールドをその値に設定することを意味します。NextHop { mac_address = 00:00:5E:00:53:00; // Next hop MAC address InterfaceRef { interface = "et-0/0/7"; subinterface = 0; } } NextHopKey { index = 1; }
-
AFTOperation
メッセージフィールドを次のように設定します。AFTOperation { Operation { ADD; } entry { next_hop; // NextHopKey object created above } }
- 上記で定義した
AFTOperation
を使用するようにModifyRequest
メッセージを設定します。 -
上記の
ModifyRequest
メッセージを使用して、Modify()
RPC を呼び出します。 -
ルートが正常にプログラムされたことを確認するには、CLI で
show route programmed
コマンドを使用します。
階層ルックアップとIP-in-IPトンネリング
gRIBIのJunos実装は、階層ルックアップをサポートしています。階層ルックアップを設定するには、IPv4 AFT を使用して、IP-IP トンネル エンドポイントとサイト グループの仮想 IP アドレス ルートをプログラムします。
IP-in-IPトンネルのイングレスノードのトラフィックをカプセル化するには、 NextHop
メッセージに以下のフィールドを設定します。
NextHop { encapsulate_header; IpInIp { dst_ip; // Destination IP address src_ip; // Source IP address } }
複数クライアントのアービトレーション
RPC Modify()
は、複数のクライアントが gRIBI サーバーに接続している場合のアービトレーションをサポートします。調停は、どのクライアントがどの操作を実行できるかを決定します。
SessionParameters
メッセージを使用して、gRIBI クライアントのパーシスタンス・モードとクライアント冗長モードを設定します。すべてのクライアントは、SessionParameters
メッセージのすべての属性の同じ値を送信する必要があります。 SessionParameters
、セッションの有効期間中に一度だけ送信する必要があります。
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
コマンドを使用します。以下に、 show route extensive
コマンドが ALL_PRIMARY
モードで表示する内容の例を示します。わかりやすくするために、出力を短くしています。
user@host> show route 10.0.1.1 extensive b4.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) 10.0.1.1/32 (1 entry, 1 announced) TSI: [...] Opaque data client: PRPD Address: ABC123 Opaque-data reference count: 2 Opaque data PRPD: client_num_ids=1,5,6 nh group Id=110
シングル プライマリ モード
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
モードで表示する内容の例を示します。わかりやすくするために、出力を短くしています。
user@host> show route 10.0.1.1 extensive b4.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) 10.0.1.1/32 (1 entry, 1 announced) TSI: [...] Opaque data client: PRPD Address: ABC123 Opaque-data reference count: 2 Opaque data PRPD: group_num_id=1 nh group Id=110
VRF インスタンスでのフォールバックルートのプログラム
静的ルートを介してネクストホップに到達できなくなった場合、ネットワークはトラフィックの中断を回避するために、代替ルートを介してトラフィックを再ルーティングできます。この代替ルートは、フォールバック ルートと呼ばれます。トラフィックがトンネルにカプセル化されていない場合は、CLI を使用して通常どおりにフォールバック静的ルートを構成します。ただし、トラフィックがトンネルにカプセル化されている場合は、gRIBI を使用して、カプセル化解除とカプセル化を含むフォールバック トンネルをプログラムできます。
VRF でフォールバック ルートをプログラムして、システムが古いトンネルからトラフィックをカプセル化解除し、新しいトンネルで再カプセル化してから、トラフィックをネクスト ホップに再ルーティングするようにすることができます。この機能は、IPv4 または IPv6 ペイロードを持つ動的 IP-IP トンネルの IPv4 トランスポートをサポートします。
カプセル化解除および再カプセル化機能を備えたフォールバック IP-in-IP トンネルをプログラムするには、 NextHop
メッセージで次のフィールドを設定します。
NextHop { decapsulate_header; encapsulate_header; network_instance; // VRF instance IpInIp { dst_ip; // Destination IP address src_ip; // Source IP address } }
トラフィック制御仮想ルーティングおよび転送(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 にある場合:
[edit] user@host# set firewall filter b4-filter term 1 from dscp cs7 user@host# set firewall filter b4-filter term 1 then count b4-count user@host# set firewall filter b4-filter term 1 then routing-instance b4 user@host# set firewall filter b4-filter term 2 then accept user@host# set interfaces et-0/0/0 unit 0 family inet filter input b4-filter
ポリシーベース転送
PolicyForwardingEntry
メッセージを使用して、gRIBI サーバーでポリシーベースの転送をプログラムします。ポリシーベースの転送により、バックアップ トンネルに移動したトラフィックは、ルーティング テーブルの内容に関係なく、トンネル内にとどまります。
一致条件を設定し、トラフィック転送のポリシーをプログラムするには:
-
Afts
メッセージで次のフィールドを設定します。PolicyForwardingEntry { ip_prefix; // To match the destination IP address src_ip_prefix; // To match the source IP address next_hop_group; }
-
AFTOperation
メッセージで次のフィールドを設定します。AFTOperation { entry { policy_forwarding_entry; // PolicyForwardingEntryKey object created above } }
- 上記で定義した
AFTOperation
を使用するようにModifyRequest
メッセージを設定します。 -
上記の
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 インスタンスからルートをフラッシュします。
変更履歴テーブル
機能のサポートは、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がプラットフォームでサポートされているかどうかを判断します。