BGP送信元の検証
BGPのオリジン検証について
送信元の検証は、ルートの意図しないアドバタイズを防ぐのに役立ちます。ネットワーク管理者は、自分が管理していないネットワークに誤ってルートをアドバタイズすることがあります。このセキュリティの問題は、オリジン検証 (セキュリティで保護されたドメイン間ルーティングとも呼ばれます) を構成することで解決できます。送信元の検証とは、予想される自律システム（AS）からの発信としてルートのアドバタイズメントを認証できるようにするメカニズムです。オリジン検証では、1 つ以上のリソース公開キー基盤 (RPKI) キャッシュサーバーを使用して、指定された BGP プレフィックスの認証を実行します。プレフィックスを認証するために、ルーター(BGPスピーカー)は、キャッシュサーバーからダウンロードされた検証済みのプレフィックスツーASマッピングのデータベースに問い合わせ、プレフィックスが予想されるASからのものであることを確認します。
RPKI認証を有効にすると、Junos OSは予告なしにTCPポート2222を自動的に開きます。フィルターを適用して、このポートをブロックし、セキュリティで保護できます。
Junos OSは、IPv4およびIPv6プレフィックスのオリジン検証をサポートしています。
図 1 サンプル トポロジーを示しています。
- サポートされている標準
- オリジン検証の仕組み
- BGP とルート検証データベースとの相互作用
- IBGPネイバーにRPKI検証状態を通知するコミュニティ属性
- ノンストップのアクティブルーティングと起点検証
- プレフィックス範囲を許可しないとしてマークする
サポートされている標準
起点検証のJunos OSの実装は、以下のRFCとドラフトをサポートしています。
RFC 6810、ルータープロトコルへのリソース公開キーインフラストラクチャ（RPKI）
RFC 6811、BGPプレフィックス原点の検証
インターネットドラフトdraft-ietf-sidr-origin-validation-signaling-00、 BGPプレフィックス起点検証ステートメント (部分サポート)
拡張コミュニティー（起点検証状態）は、Junos OSルーティングポリシーでサポートされています。ルート選択手順の指定変更はサポートされていません。
オリジン検証の仕組み
RPKIとオリジンの検証では、RFC 3779の IPアドレスとAS識別子のX.509拡張で指定された拡張子を持つX.509証明書を使用します。
RPKI は、分散した情報の集まりで構成されています。各証明機関は、エンドエンティティ (EE) 証明書、証明書失効リスト (CRL)、および署名付きオブジェクトを特定の場所で公開します。これらのリポジトリはすべて、すべてのRPKIキャッシュサーバーで使用できる情報の完全なセットを形成します。
各 RPKI キャッシュ サーバーは、ローカル キャッシュ内の各要素を元のリポジトリ公開ポイントと定期的に同期することによって、分散リポジトリ コレクション全体のローカル キャッシュを維持します。
ルータでは、データベース エントリは ルート検証(RV)レコードとしてフォーマットされます。RVレコードは（プレフィックス、最大長、送信元ASの）トリプルです。プレフィックスがRVプレフィックスと一致し、プレフィックス長がRVレコードで指定された最大長を超えず、送信元ASがRVレコードで指定された送信元ASと等しいルートに一致します。
RV レコードは、 ルート起点認証(ROA)の簡易バージョンです。ROAはデジタル署名されたオブジェクトで、IPアドレスブロックの所有者が、アドレスブロック内の1つまたは複数のプレフィックスに対するルート発信をASに承認していることを確認する手段を提供します。ROAはルート検証では直接使用されません。キャッシュサーバーは、ROAの簡略化されたバージョンをRVレコードとしてルーターにエクスポートします。
最大長の値は、許可されたプレフィックスの長さ以上で、アドレスファミリーのIPアドレスの長さ(ビット単位)以下である必要があります(IPv4の場合は32、IPv6の場合は128)。最大長は、ASがアドバタイズする許可を得ているIPアドレスプレフィックスを定義します。
たとえば、IPアドレスプレフィックスが200.4.66/24で、最大長が26の場合、ASは200.4.66.0/24、200.4.66.0/25、200.4.66.128/25、200.4.66.0/26、200.4.66.64/26、200.4.66.128/26、および200.4.66.192/26をアドバタイズすることを許可されます。最大長が存在しない場合、ASはRVで指定されたプレフィックスを正確にアドバタイズすることのみが許可されます。
別の例として、RVには、最大長26のプレフィックス200.4.66/24と、最大長28のプレフィックス200.4.66.0/28を含めることができます。このRVは、200.4.66で始まり、長さが24以上26以下のプレフィックスと、特定のプレフィックス200.4.66.0/28をアドバタイズすることをASに許可します。
ルートの起点は、AS_PATH属性の一番右にあるAS番号によって表されます。送信元の検証では、ルーティング更新内の送信元ASと、RVレコードに公開された承認済みのソースASを比較します。
送信元検証のみによって提供されるセキュリティは、ソースASに不正侵入している攻撃者などを防ぐことができないため、確定的な攻撃者に対して脆弱であることがわかっています。とはいえ、オリジン検証は、偶発的な発表に対する有用な保護を提供します。
送信元の検証は、各ルーターを RPKI に直接参加させることで実装できますが、(RPKI データの検証には多くの公開キー暗号化操作が必要なため)リソースを大量に消費するだけでなく、各ルーターで RPKI 構成を設定して維持するには運用負荷が高すぎると見なされます。このため、別のRPKIキャッシュサーバーは公開キーの検証を実行し、プレフィックスツーASマッピングの検証済みデータベースを生成します。検証されたデータベースは、安全なTCP接続を介してクライアントルーターにダウンロードされます。したがって、ルーターはRPKIインフラストラクチャに関する情報をほとんど必要とせず、暗号化されたトランスポートパスワード以外の公開キー暗号化要件もありません。その後、ルーターはダウンロードしたデータを使用して、受信したルート更新を検証します。
サーバー セッションを構成するときに、セッションをグループ化し、グループ内の各セッションのセッション パラメーターを構成できます。ルーターは、キャッシュサーバーへの構成可能な最大接続数を定期的に設定しようとします。接続のセットアップに失敗した場合は、定期的に新しい接続が試行されます。
それまでの間、検証インポートポリシーがBGPセッションに適用されると、キャッシュセッションの状態(アップまたはダウン)とRVデータベース(空または空ではない)に関係なく、ルート検証が実行されます。RV データベースが空であるか、どのキャッシュ サーバ セッションも稼働していない場合、受信した BGP プレフィックスを評価するための RV レコードが存在しないため、各ルートの検証状態は不明に設定されます。
再試行の期間は構成可能です。キャッシュ サーバに正常に接続した後、ルータは最新のデータベースのシリアル番号を照会し、RPKI キャッシュがそのバージョンのデータベースに属するすべての RV エントリを送信するように要求します。
各インバウンドメッセージは、RPKI キャッシュサーバーのライブタイマーをリセットします。すべての更新が学習された後、ルーターは設定可能な間隔に基づいて定期的にライブ性チェックを実行します。これは、キャッシュサーバーが最新の通知PDUで報告したのと同じシリアル番号を持つシリアルクエリプロトコルデータユニット(PDU)を送信することによって行われます。キャッシュ サーバーは、0 回以上の更新とデータ終了 (EOD) PDU で応答し、キャッシュ サーバーのライブ状態を更新し、レコードの有効期間タイマーをリセットします。
外部BGP(EBGP)ピアからプレフィックスを受信すると、インポートポリシーによって検査され、有効、無効、不明、または未検証としてマークされます。
有効—プレフィックスとASのペアがデータベースに存在することを示します。
無効—プレフィックスは見つかったが、EBGPピアから受信した対応するASがデータベースに表示されるASではないか、BGPアップデートメッセージのプレフィックス長がデータベースで許可されている最大長を超えていることを示します。
不明—プレフィックスがデータベース内のプレフィックスまたはプレフィックス範囲に含まれていないことを示します。
未検証—プレフィックスの発信元がデータベースに対して検証されていないことを示します。これは、オリジン検証が有効になっているか、BGPピアに対してオリジン検証が有効になっていないにもかかわらず、データベースにデータが入力され、BGPインポートポリシーで検証が呼び出されないためです。
検証データベース内のルートに一致する可能性がある場合、ルートが有効になるには、そのうちの 1 つと一致する必要があります。それ以外の場合は無効です。ルートを有効にするには、どの一致でも十分です。ベストマッチである必要はありません。一致する可能性のあるルートがない場合にのみ、ルートは不明と見なされます。プレフィックスからASへのマッピングデータベースロジックの詳細については、インターネットドラフトdraft-ietf-sidr-pfx-validate-01のセクション2、 BGPプレフィックス原点の検証を参照してください。
RPKI 検証は、プライマリ インスタンスでのみ使用できます。ルーティングインスタンスにRPKI検証を設定した場合、RPKI検証は失敗し、以下のエラーメッセージ RV instance is not runningが表示されます。
BGP とルート検証データベースとの相互作用
ルート検証(RV)データベースには、ルーターがRPKIキャッシュサーバーからダウンロードするRVレコードのコレクションが含まれています。RV データベースに RV レコードが入力された後、RV データベースは RIB-Local ルーティング テーブルをスキャンして、データベース内の RV レコードの影響を受ける可能性のあるプレフィックスが RIB-Local にあるかどうかを判断します。(RIB-Localには、 show route protocol bgp コマンドの出力に示されているIPv4およびIPv6ルートが含まれています。)
このプロセスにより、BGPインポートポリシー(エクスポートポリシーではない)のBGP再評価がトリガーされます。
図 2 にプロセスを示します。
インポートポリシーは RIB-In に適用されます。これを理解する別の方法は、インポート・ポリシーは show route receive-protocol bgp コマンドの出力に表示されるルートに適用され、エクスポート・ポリシーは show route advertising-protocol bgp コマンドで示されるルートに適用されるということです。
図 3に示すように、インポートルーティングポリシーを使用してBGPがルーティングテーブルに配置するルートを制御し、ルーティングポリシーのエクスポートを使用して、BGPがルーティングテーブルからネイバーにアドバタイズするルートを制御します。
ルート検証インポートポリシーを設定する場合、そのポリシー設定は validation-database 一致条件を使用します。この一致条件は、RVデータベースで、特定のルーティングインスタンスにおけるプレフィックスの検証状態に対するクエリーをトリガーします。デフォルトの操作は、ルーティングインスタンスに一致する検証データベースへのクエリを実行することです。ルート検証インスタンスが見つからない場合は、プライマリ インスタンスが照会されます。
次のBGPインポートポリシーでは、 from validation-database 条件はルーターのRVデータベースでの検索をトリガーします。検証状態が有効な場合は、アクションが実行されます。アクションは、ルートを受け入れ、ルーティングテーブル内の validation-state を有効にするように設定することです。
[edit protocols bgp] import validation;
[edit policy-options]
policy-statement validation-1 {
term valid {
from {
protocol bgp;
validation-database valid; # Triggers a lookup in the RV database
}
then {
validation-state valid; # Sets the validation state in the routing table
accept;
}
}
}
IBGPネイバーにRPKI検証状態を通知するコミュニティ属性
プレフィックス検証は、外部 BGP(EBGP)更新に対してのみ実行されます。AS内では、すべての内部BGP（IBGP）ルーターでRPKIセッションを実行しないようにすることがあります。代わりに、すべての IBGP スピーカーが一貫した情報を持つように、IBGP メッシュ間で検証状態を伝送する方法が必要です。これは、非移行性拡張コミュニティーで検証状態を伝送することによって実現されます。コミュニティ属性は、IBGPネイバー間のプレフィックスの検証状態を通知および受信します。
Junos OSは、ルート検証のために、以下のよく知られた拡張コミュニティをサポートしています。
起点検証状態有効
起点検証状態が無効です
送信元-検証-状態-不明
次のサンプルBGPインポートポリシーは、RPKIサーバーとのセッションを持つルーターで設定されています。
RPKIセッションを持つルーター
policy-statement validation-1 {
term valid {
from {
protocol bgp;
validation-database valid;
}
then {
validation-state valid;
community add origin-validation-state-valid;
accept;
}
}
}
以下のサンプルBGPインポートポリシーは、RPKIサーバーとのセッションを持たないIBGPピアルーターで設定されています。
RPKI セッションのない IBGP ピア ルーター
policy-statement validation-2 {
term valid {
from community origin-validation-state-valid;
then validation-state valid;
}
}
ノンストップのアクティブルーティングと起点検証
デュアルルーティングエンジンを搭載し、 ノンストップアクティブルーティング が有効になっているルーターで起点検証を設定すると、プライマリとスタンバイの両方のルーティングエンジンがRVデータベースのコピーを持つことになります。これら 2 つの RV データベースは、互いに同期されたままになります。
ルーターは、RPKI サーバーとの 2 つの同一のセッションを維持しません。RPKI-RTRプロトコルは、プライマリルーティングエンジンのみで動作します。スタンバイ ルーティング エンジンでは、RPKI キャッシュ サーバー セッションは常にダウンしています。
RV データベースは、RPKI サーバーとのセッションを通じて、プライマリ ルーティング エンジンによってアクティブに維持されます。このデータベースは、スタンバイ ルーティング エンジンに複製されます。セッションはスタンバイ ルーティング エンジンでダウンしていますが、レプリケートされた RV データベースには RV レコードが含まれています。スタンバイ ルーティング エンジンが切り替わってプライマリ ルーティング エンジンになると、すでに完全に設定された RV データベースがあります。
2 つのデータベースの内容を表示するには、 show validation database コマンドと show validation replication database コマンドを使用します。
プレフィックス範囲を許可しないとしてマークする
ルート検証モデルには、次の 1 つの大きな欠点があります。それは肯定的な更新を提供するだけです。どのASがプレフィックスの正規所有者かを宣言できます。ただし、次のように、否定的な更新を明示的に伝えることはできません。このプレフィックスは、指定されたASから発信されることはありません。この機能は、AS 0の回避策を使用してある程度提供できます。
Junos OS の実装は、キャッシュからの入力を制限しようとはしません。たとえば、送信元AS 0を持つRVレコードは、他のものと同様にインストールされ、照合されます。これにより、AS 0は有効なASではないため、プレフィックス範囲を絶対に通知できないとしてマークする回避策が可能になります。RVレコード内のASが、EBGPピアから受信したASと一致することはありません。したがって、一致するプレフィックスはすべて無効とマークされます。
関連項目
BGPのオリジン検証のユースケースとメリット
自律システム(AS)の管理者が他社に割り当てられたネットワークの全部または一部をアドバタイズし始めた場合、BGPにはエラーを認識し、サービスの中断を回避するような方法で応答する方法が組み込まれていません。
例えば、顧客ネットワークの管理者が誤ってルート(例えば10.65.153.0/24)をアドバタイズし、顧客のサービスプロバイダAS 1にトラフィックを誘導したとします。この/24ルートは、トラフィックをAS 2に転送する実際のコンテンツプロバイダ(10.65.152.0/22)が使用するルートよりも、より具体的なルートです。ルーターの仕組み上、ほとんどのルーターはより具体的なルートを選択し、AS 2ではなくAS 1にトラフィックを送信します。
ハイジャックされたプレフィックスは、トランジットルーターが更新されたパス情報を伝播するため、インターネット上で広く見られます。デフォルトのフリーゾーン(DFZ)のルーターがハイジャックされたルートを伝送するため、無効なルートはインターネット全体に広く配布される可能性があります。最終的には、正しいASパスがBGPピアに復元されますが、それまでは、サービスの中断が予想されます。
BGPは推移的な信頼モデルに依存しているため、顧客とプロバイダ間の検証が重要です。上記の例では、サービスプロバイダAS 1は、10.65.153.0/24の不具合のあるアドバタイズメントを検証しませんでした。このアドバタイズメントを受け取って、それをそのピアとプロバイダに再アドバタイズすることで、AS 1は間違ったルートを伝達していました。このルートをAS 1から受け取るルーターは、そのルートがより具体的なルートであるという理由でそれを選択しました。実際のコンテンツプロバイダーは、間違いが発生する前に10.65.152.0/22を宣伝していました。/24は、より小さな(そしてより具体的な)広告でした。通常のBGPルート選択プロセスに従って、/ 24が選択され、ハイジャックが事実上完了しました。
コンテンツプロバイダーの迅速な検出と反応、および他のプロバイダーとの協力があっても、それらのプレフィックスのサービスは、何分から数時間まで中断される可能性があります。停止の正確な期間は、インターネット上の見晴らしの良い場所によって異なります。この種のイベントが発生した場合、この脆弱性の解決策に新たな関心が寄せられます。BGPはプロバイダー関係の基本であり、すぐになくなることはありません。この例では、オリジン検証を使用するソリューションを示します。このソリューションは、BGPの暗号拡張と、ルーターCPUに過剰な負荷をかけない分散型クライアントサーバーモデルに依存しています。
オリジン検証は、プロバイダーが顧客から受け入れるアドバタイズを制限できるようにすることで、推移的な信頼の脆弱性を克服するのに役立ちます。メカニズムには、拡張BGPコミュニティ属性に基づくルーティングポリシーの通信が含まれます。
関連項目
例：BGPのオリジン検証の設定
この例では、受信したルートアドバタイズメントが予想される自律システム(AS)から送信(発信)されるようにすることで、BGPピア間の送信元検証を設定する方法を示します。送信元ASが検証済みの場合、ポリシーでは、プレフィックスが同様にアドバタイズされるように指定できます。
要件
この例には、次のハードウェア要件とソフトウェア要件があります。
-
リソース公開鍵基盤(RPKI)キャッシュサーバー、サードパーティのソフトウェアを使用してBGPプレフィックスを認証します。
-
TCP接続を介してキャッシュサーバーと通信するルーティングデバイスで実行されているJunos OSリリース12.2以降。
概要
オペレーターのエラーにより、意図せずにルートがアドバタイズされることがあります。このセキュリティ上の問題を防止するには、BGPを設定して、発信元のASを検証し、これらの無効なアナウンスを拒否します。 この機能は、キャッシュサーバーを使用してプレフィックスまたはプレフィックス範囲を認証します。
以下の設定ステートメントで、元のAS検証を有効にします。
[edit routing-options] validation { group group-name { max-sessions number; session address { hold-time seconds; local-address local-ip-address; port port-number; preference number; record-lifetime seconds; refresh-time seconds; traceoptions { file filename <files number> <size size> <(world-readable | no-world-readable)>; flag flag { disable; flag-modifier; } } } static { record destination { maximum-length prefix-length { origin-autonomous-system as-number { validation-state (invalid | valid); } } } } traceoptions { file filename <files number> <size size> <world-readable | no-world-readable>; flag flag { disable; flag-modifier; } } }
この例では、検証パラメーターの既定の設定を使用します。
使用可能な設定ステートメントのほとんどはオプションです。必要な設定は次のとおりです。
validation { group group-name { session address { } } }
[edit routing-options validation static]階層レベルでは、ルーティングデバイス上に静的レコードを設定し、RPKIキャッシュサーバーから受信したレコードを上書きすることができます。
たとえば、以下のように表示されます。
[edit routing-options validation] user@R0# set static record 10.0.0.0/16 maximum-length 24 origin-autonomous-system 200 validation-state valid
ルート プレフィックスの検証状態に基づいて動作するルーティング ポリシーを設定できます。コミュニティ属性を使用して、外部BGP(EBGP)と内部BGP(IBGP)ピア間のプレフィックスの検証状態を通知および受信できます。ルーターによっては、RPKIサーバーとのセッションを設定するよりも、ルーティング・ポリシーを使用する方が便利な場合があります。この例では、IBGPピア間での検証状態コミュニティ属性の使用方法を示します。
図 4サンプルのトポロジーを示しています。
この例では、デバイス R0 にはデバイス R1 への IBGP 接続とデバイス R2 への EBGP 接続があります。デバイスR0は、インターネットドラフトdraft-ietf-sidr-rpki-rtr-19、 RPKI/ルータープロトコル で定義されたプロトコルを使用して、キャッシュサーバーからルート検証(RV)レコードを受信し、RVレコードを送信します。RPKI-Router ProtocolはTCP上で実行されます。RV レコードは、ローカル RV データベースを構築するためにデバイス R0 によって使用されます。デバイス R1 では、ルートで受信した validation-state と呼ばれる BGP コミュニティに基づいて検証状態が設定されます。
設定
CLIクイック構成
この例をすばやく設定するには、次のコマンドをコピーしてテキストファイルに貼り付け、改行を削除して、ネットワーク構成に合わせて必要な詳細を変更し、[edit]階層レベルのCLIにコマンドをコピー＆ペーストしてください。
デバイスR0
set interfaces ge-1/2/0 unit 2 description to-R1 set interfaces ge-1/2/0 unit 0 family inet address 10.0.0.2/30 set interfaces ge-1/2/1 unit 0 description to-R2 set interfaces ge-1/2/1 unit 0 family inet address 10.0.0.5/30 set interfaces ge-1/2/2 unit 0 description to-cache set interfaces ge-1/2/2 unit 0 family inet address 10.0.0.9/30 set interfaces lo0 unit 0 family inet address 10.0.1.1/32 set protocols bgp group int type internal set protocols bgp group int local-address 10.0.1.1 set protocols bgp group int export send-direct set protocols bgp group int neighbor 10.1.1.1 set protocols bgp group ext type external set protocols bgp group ext import validation set protocols bgp group ext export send-direct set protocols bgp group ext peer-as 65200 set protocols bgp group ext neighbor 10.0.0.6 set protocols ospf area 0.0.0.0 interface ge-1/2/0.2 set protocols ospf area 0.0.0.0 interface lo0.0 passive set policy-options policy-statement send-direct from protocol direct set policy-options policy-statement send-direct then accept set policy-options policy-statement validation term valid from protocol bgp set policy-options policy-statement validation term valid from validation-database valid set policy-options policy-statement validation term valid then validation-state valid set policy-options policy-statement validation term valid then community add origin-validation-state-valid set policy-options policy-statement validation term valid then accept set policy-options policy-statement validation term invalid from protocol bgp set policy-options policy-statement validation term invalid from validation-database invalid set policy-options policy-statement validation term invalid then validation-state invalid set policy-options policy-statement validation term invalid then community add origin-validation-state-invalid set policy-options policy-statement validation term invalid then reject set policy-options policy-statement validation term unknown from protocol bgp set policy-options policy-statement validation term unknown then validation-state unknown set policy-options policy-statement validation term unknown then community add origin-validation-state-unknown set policy-options policy-statement validation term unknown then accept set policy-options community origin-validation-state-invalid members 0x4300:0.0.0.0:2 set policy-options community origin-validation-state-unknown members 0x4300:0.0.0.0:1 set policy-options community origin-validation-state-valid members 0x4300:0.0.0.0:0 set routing-options autonomous-system 65100 set routing-options validation group test session 10.0.0.10
デバイスR1
set interfaces ge-1/2/0 unit 0 family inet address 10.0.0.1/30 set interfaces lo0 unit 0 family inet address 10.1.1.1/32 set protocols bgp group int type internal set protocols bgp group int local-address 10.1.1.1 set protocols bgp group int import validation-ibgp set protocols bgp group int neighbor 10.0.1.1 set protocols ospf area 0.0.0.0 interface ge-1/2/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set policy-options policy-statement validation-ibgp term valid from community origin-validation-state-valid set policy-options policy-statement validation-ibgp term valid then validation-state valid set policy-options policy-statement validation-ibgp term invalid from community origin-validation-state-invalid set policy-options policy-statement validation-ibgp term invalid then validation-state invalid set policy-options policy-statement validation-ibgp term unknown from community origin-validation-state-unknown set policy-options policy-statement validation-ibgp term unknown then validation-state unknown set policy-options community origin-validation-state-invalid members 0x4300:0.0.0.0:2 set policy-options community origin-validation-state-unknown members 0x4300:0.0.0.0:1 set policy-options community origin-validation-state-valid members 0x4300:0.0.0.0:0 set routing-options autonomous-system 65100
デバイスR2
set interfaces ge-1/2/0 unit 0 family inet address 10.0.0.6/30 set interfaces lo0 unit 0 family inet address 172.16.1.1/32 set interfaces lo0 unit 0 family inet address 192.168.2.3/32 set protocols bgp group ext export send-direct set protocols bgp group ext peer-as 65100 set protocols bgp group ext neighbor 10.0.0.5 set policy-options policy-statement send-direct from protocol direct set policy-options policy-statement send-direct from protocol local set policy-options policy-statement send-direct then accept set routing-options autonomous-system 65200
デバイス R0 の設定
ステップバイステップでの手順
次の例では、設定階層のいくつかのレベルに移動する必要があります。CLIのナビゲーションについては、Junos OS CLIユーザーガイドの 設定モードでCLIエディターを使用する を参照してください。
Device R0を設定するには：
-
インターフェイスを設定します。
[edit interfaces] user@R0# set ge-1/2/0 unit 0 description to-R1 user@R0# set ge-1/2/0 unit 0 family inet address 10.0.0.2/30 user@R0# set ge-1/2/1 unit 0 description to-R2 user@R0# set ge-1/2/1 unit 0 family inet address 10.0.0.5/30 user@R0# set ge-1/2/2 unit 0 description to-cache user@R0# set ge-1/2/2 unit 0 family inet address 10.0.0.9/30 user@R0# set lo0 unit 0 family inet address 10.0.1.1/32
-
BGP を設定します。
send-directエクスポートポリシーを適用して、ルーティングテーブルからBGPに直接ルートがエクスポートされるようにします。validationインポートポリシーを適用して、デバイスR0のEBGPピアからインポート(または受信)されたすべてのルートの検証状態とBGPコミュニティ属性を設定します。デバイスR1とのIBGPセッションを設定します。デバイスR2とのEBGPセッションを設定します。
[edit protocols bgp] user@R0# set group int type internal user@R0# set group int local-address 10.0.1.1 user@R0# set group int export send-direct user@R0# set group int neighbor 10.1.1.1 user@R0# set group ext type external user@R0# set group ext import validation user@R0# set group ext export send-direct user@R0# set group ext peer-as 65200 user@R0# set group ext neighbor 10.0.0.6
-
IBGPピアに面するインターフェイスとループバックインターフェイスにOSPF(または別の内部ゲートウェイプロトコル[IGP])を設定します。
注:IBGP
neighborステートメントでループバック インターフェイス アドレスを使用する場合は、ループバック インターフェイスで IGP を有効にする必要があります。それ以外の場合、IBGP セッションは確立されません。[edit protocols ospf area 0.0.0.0] user@R0# set interface ge-1/2/0.0 user@R0# set interface lo0.0 passive
-
ルーティングテーブルからBGPに直接ルートをエクスポートするルーティングポリシーを設定します。
[edit policy-options policy-statement send-direct] user@R0# set from protocol direct user@R0# set then accept
-
各 BGP ルートの検証状態に基づいて変更する属性を指定するルーティング ポリシーを構成します。
[edit policy-options policy-statement validation] user@R0# set term valid from protocol bgp user@R0# set term valid from validation-database valid user@R0# set term valid then validation-state valid user@R0# set term valid then community add origin-validation-state-valid user@R0# set term valid then accept user@R0# set term invalid from protocol bgp user@R0# set term invalid from validation-database invalid user@R0# set term invalid then validation-state invalid user@R0# set term invalid then community add origin-validation-state-invalid user@R0# set term invalid then reject user@R0# set term unknown from protocol bgp user@R0# set term unknown then validation-state unknown user@R0# set term unknown then community add origin-validation-state-unknown user@R0# set term unknown then accept [edit policy-options] user@R0# set community origin-validation-state-invalid members 0x4300:0.0.0.0:2 user@R0# set community origin-validation-state-unknown members 0x4300:0.0.0.0:1 user@R0# set community origin-validation-state-valid members 0x4300:0.0.0.0:0
-
RPKI キャッシュ サーバーとのセッションを構成します。
[edit routing-options validation] user@R0# set group test session 10.0.0.10
-
自律システム（AS）番号を設定します。
[edit routing-options] user@R0# set autonomous-system 65100
結果
設定モードから、show interfaces 、show protocols、show policy-options、およびshow routing-options のコマンドを入力して設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の手順を繰り返して設定を修正します。
user@R0# show interfaces
ge-1/2/0 {
unit 0 {
description to-R1;
family inet {
address 10.0.0.2/30;
}
}
}
ge-1/2/1 {
unit 0 {
description to-R2;
family inet {
address 10.0.0.5/30;
}
}
}
ge-1/2/2 {
unit 0 {
description to-cache;
family inet {
address 10.0.0.9/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.0.1.1/32;
}
}
}
user@R0# show protocols
bgp {
group int {
type internal;
local-address 10.0.1.1;
export send-direct;
neighbor 10.1.1.1;
}
group ext {
type external;
import validation;
export send-direct;
peer-as 65200;
neighbor 10.0.0.6;
}
}
ospf {
area 0.0.0.0 {
interface ge-1/2/0.0;
interface lo0.0 {
passive;
}
}
}
user@R0# show policy-options
policy-statement send-direct {
from protocol direct;
then accept;
}
policy-statement validation {
term valid {
from {
protocol bgp;
validation-database valid;
}
then {
validation-state valid;
community add origin-validation-state-valid;
accept;
}
}
term invalid {
from {
protocol bgp;
validation-database invalid;
}
then {
validation-state invalid;
community add origin-validation-state-invalid;
reject;
}
}
term unknown {
from protocol bgp;
then {
validation-state unknown;
community add origin-validation-state-unknown;
accept;
}
}
}
community origin-validation-state-invalid members 0x4300:0.0.0.0:2;
community origin-validation-state-unknown members 0x4300:0.0.0.0:1;
community origin-validation-state-valid members 0x4300:0.0.0.0:0;
}
user@R0# show routing-options
autonomous-system 65100;
validation {
group test {
session 10.0.0.10;
}
}
デバイスの設定が完了したら、設定モードから commit を入力します。
デバイスR1の設定
ステップバイステップでの手順
次の例では、設定階層のいくつかのレベルに移動する必要があります。CLIのナビゲーションについては、Junos OS CLIユーザーガイドの 設定モードでCLIエディターを使用する を参照してください。
Device R1を設定するには：
-
インターフェイスを設定します。
[edit interfaces] user@R1# set ge-1/2/0 unit 0 family inet address 10.0.0.1/30 user@R1# set lo0 unit 0 family inet address 10.1.1.1/32
-
BGP を設定します。
validation-ibgpインポートポリシーを適用して、デバイスR1のIBGPピアから受信したすべてのルートの検証状態とBGPコミュニティ属性を設定します。デバイスR0とのIBGPセッションを設定します。
[edit protocols bgp group int] user@R1# set type internal user@R1# set local-address 10.1.1.1 user@R1# set import validation-ibgp user@R1# set neighbor 10.0.1.1
-
OSPFを設定します。
[edit protocols ospf area 0.0.0.0] user@R1# set interface ge-1/2/0.0 user@R1# set interface lo0.0 passive
-
デバイス R0 から受信した BGP ルートの検証状態 BGP コミュニティ属性に基づいて、変更する属性を指定するルーティング ポリシーを構成します。
[edit policy-options policy-statement validation-ibgp] user@R1# set term valid from community origin-validation-state-valid user@R1# set term valid then validation-state valid user@R1# set term invalid from community origin-validation-state-invalid user@R1# set term invalid then validation-state invalid user@R1# set term unknown from community origin-validation-state-unknown user@R1# set term unknown then validation-state unknown [edit policy-options] user@R1# set community origin-validation-state-invalid members 0x4300:0.0.0.0:2 user@R1# set community origin-validation-state-unknown members 0x4300:0.0.0.0:1 user@R1# set community origin-validation-state-valid members 0x4300:0.0.0.0:0
-
自律システム（AS）番号を設定します。
[edit routing-options] user@R1# set autonomous-system 65100
結果
設定モードから、show interfaces 、show protocols、show policy-options、およびshow routing-options のコマンドを入力して設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の手順を繰り返して設定を修正します。
user@R1# show interfaces
ge-1/2/0 {
unit 0 {
family inet {
address 10.0.0.1/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.1.1.1/32;
}
}
}
user@R1# show protocols
bgp {
group int {
type internal;
local-address 10.1.1.1;
import validation-ibgp;
neighbor 10.0.1.1;
}
}
ospf {
area 0.0.0.0 {
interface ge-1/2/0.0;
interface lo0.0 {
passive;
}
}
}
user@R1# show policy-options
policy-statement validation-ibgp {
term valid {
from community origin-validation-state-valid;
then validation-state valid;
}
term invalid {
from community origin-validation-state-invalid;
then validation-state invalid;
}
term unknown {
from community origin-validation-state-unknown;
then validation-state unknown;
}
}
community origin-validation-state-invalid members 0x4300:0.0.0.0:2;
community origin-validation-state-unknown members 0x4300:0.0.0.0:1;
community origin-validation-state-valid members 0x4300:0.0.0.0:0;
}
user@R1# show routing-options autonomous-system 65100;
デバイスの設定が完了したら、設定モードから commit を入力します。
デバイスR2の設定
ステップバイステップでの手順
次の例では、設定階層のいくつかのレベルに移動する必要があります。CLIのナビゲーションについては、Junos OS CLIユーザーガイドの 設定モードでCLIエディターを使用する を参照してください。
デバイスR2 を設定するには：
-
インターフェイスを設定します。
ループバックインターフェイスには、デモンストレーション用のルートとして機能するいくつかのアドレスが設定されています。
[edit interfaces] user@R2# set ge-1/2/0 unit 0 family inet address 10.0.0.6/30 user@R2# set lo0 unit 0 family inet address 172.16.1.1/32 user@R2# set lo0 unit 0 family inet address 192.168.2.3/32
-
BGP を設定します。
[edit protocols bgp] user@R2# set group ext export send-direct user@R2# set group ext peer-as 65100 user@R2# set group ext neighbor 10.0.0.5
-
ルーティングポリシーを設定します。
[edit policy-options policy-statement send-direct] user@R2# set from protocol direct user@R2# set from protocol local user@R2# set then accept
-
自律システム（AS）番号を設定します。
[edit routing-options] user@R2# set autonomous-system 65200
結果
設定モードから、show interfaces 、show protocols、show policy-options、およびshow routing-options のコマンドを入力して設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の手順を繰り返して設定を修正します。
user@R2# show interfaces
ge-1/2/0 {
unit 0 {
family inet {
address 10.0.0.6/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 172.16.1.1/32;
address 192.168.2.3/32;
}
}
}
user@R2# show protocols
bgp {
group ext {
export send-direct;
peer-as 65100;
neighbor 10.0.0.5;
}
}
user@R2# show policy-options
policy-statement send-direct {
from protocol [ direct local ];
then accept;
}
user@R2# show routing-options autonomous-system 65200;
デバイスの設定が完了したら、設定モードから commit を入力します。
検証
設定が正常に機能していることを確認します。
変更した属性がルーティングテーブルに表示されていることを確認
目的
デバイスR0とデバイスR1のBGPルートが、予期される検証状態と想定されるローカルプリファレンスを備えていることを確認します。
アクション
動作モードからshow routeコマンドを入力します。
user@R0> show route
inet.0: 12 destinations, 13 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.1.1/32 *[Direct/0] 04:53:39
> via lo0.1
10.1.1.1/32 *[OSPF/10] 04:50:53, metric 1
> to 10.0.0.1 via lt-1/2/0.2
10.0.0.0/30 *[Direct/0] 04:51:44
> via lt-1/2/0.2
10.0.0.2/32 *[Local/0] 04:51:45
Local via lt-1/2/0.2
10.0.0.4/30 *[Direct/0] 04:51:44
> via lt-1/2/0.5
[BGP/170] 02:24:57, localpref 100
AS path: 65200 I, validation-state: valid
> to 10.0.0.6 via lt-1/2/0.5
10.0.0.5/32 *[Local/0] 04:51:45
Local via lt-1/2/0.5
10.0.0.8/30 *[Direct/0] 03:01:28
> via lt-1/2/0.9
10.0.0.9/32 *[Local/0] 04:51:45
Local via lt-1/2/0.9
172.16.1.1/32 *[BGP/170] 02:24:57, localpref 100
AS path: 65200 I, validation-state: invalid
> to 10.0.0.6 via lt-1/2/0.5
192.168.2.3/32 *[BGP/170] 02:24:57, localpref 100
AS path: 65200 I, validation-state: validation-state: unknown
> to 10.0.0.6 via lt-1/2/0.5
224.0.0.5/32 *[OSPF/10] 04:53:46, metric 1
MultiRecvuser@R1> show route
inet.0: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.1/32 *[BGP/170] 00:40:52, localpref 100, from 1.0.1.1
AS path: 65200 I, validation-state: invalid
> to 10.0.0.2 via lt-1/2/0.1
192.168.2.3/32 *[BGP/170] 01:06:58, localpref 100, from 1.0.1.1
AS path: 65200 I, validation-state: unknown
> to 10.0.0.2 via lt-1/2/0.1
224.0.0.5/32 *[OSPF/10] 04:57:09, metric 1
MultiRecv意味
ルートには、RPKIキャッシュサーバーから受信した情報に基づいて、予想される検証状態とローカルプリファレンス値があります。
トレース操作の使用
目的
起点検証のためのトレース操作を設定し、新たにアドバタイズされたルートの結果を監視します。
アクション
-
デバイス R0 で、トレースを構成します。
[edit routing-options validation traceoptions] user@R0# set file rv-tracing user@R0# set flag all user@R0# commit
-
デバイスR2で、ループバックインターフェイスに別のアドレスを追加してルートを追加します。
[edit interfaces lo0 unit 0 family inet] user@R2# set address 10.4.4.4/32 user@R2# commit
-
デバイス R0 で、トレース ファイルを確認します。
user@R0> file show /var/log/rv-tracing Jan 27 11:27:43.804803 rv_get_policy_state: rt 10.4.4.4/32 origin-as 65200, validation result valid Jan 27 11:27:43.944037 task_job_create_background: create prio 7 job Route-validation GC for task Route Validation Jan 27 11:27:43.986580 background dispatch running job Route-validation GC for task Route Validation Jan 27 11:27:43.987374 task_job_delete: delete background job Route-validation GC for task Route Validation Jan 27 11:27:43.987463 background dispatch completed job Route-validation GC for task Route Validation
意味
ルート検証は期待どおりに動作しています。
検証情報の表示
目的
さまざまな検証コマンドを実行します。
アクション
user@R0> show validation statistics Total RV records: 2 Total Replication RV records: 2 Prefix entries: 2 Origin-AS entries: 2 Memory utilization: 9789 bytes Policy origin-validation requests: 114 Valid: 32 Invalid: 54 Unknown: 28 BGP import policy reevaluation notifications: 156 inet.0, 156 inet6.0, 0
user@R0> show validation database RV database for instance master Prefix Origin-AS Session State Mismatch 10.0.0.0/8-32 65200 10.0.0.10 valid 172.0.0.0/8-12 65200 10.0.0.10 invalid IPv4 records: 2 IPv6 records: 0
user@R0> show validation replication database RRV replication database for instance master Prefix Origin-AS Session State 10.0.0.0/8-32 65200 10.0.0.10 valid 172.0.0.0/8-12 65200 10.0.0.10 invalid IPv4 records: 2 IPv6 records: 0
user@R0> show validation group
master
Group: test, Maximum sessions: 2
Session 10.0.0.10, State: Connect, Preference: 100user@R0> show validation session Session State Flaps Uptime #IPv4/IPv6 records 10.0.0.10 Up 0 00:02:28 1/0
user@R0> request validation policy Enqueued 2 IPv4 records Enqueued 0 IPv6 records