BGPオリジンの検証
BGPのオリジン検証について
送信元の検証は、意図しないルートのアドバタイズを防ぐのに役立ちます。ネットワーク管理者が、自分たちが管理していないネットワークへのルートを誤ってアドバタイズしてしまうことがあります。このセキュリティ問題は、送信元検証(セキュアなドメイン間ルーティングとも呼ばれます)を設定することで解決できます。送信元の検証とは、予想される自律システム(AS)からの発信としてルートアドバタイズメントを認証できるようにするメカニズムです。送信元の検証では、1つ以上のリソース公開鍵基盤(RPKI)キャッシュサーバーを使用して、指定されたBGPプレフィックスの認証を実行します。プレフィックスを認証するために、ルーター(BGPスピーカー)は、キャッシュサーバーからダウンロードされた検証済みのプレフィックスからASへのマッピングのデータベースにクエリーし、プレフィックスが予想されるASから発信されたことを確認します。
Junos OSリリース20.1R3、20.2R3、20.3R2、20.4R2、21.1R1以前は、RPKI認証を有効にすると、Junos OSは予告なしにTCPポート2222を自動的に開きます。フィルターを適用して、このポートをブロックし、保護できます。
Junos OSリリース20.1R3、20.2R3、20.3R2、20.4R2、21.1R1以降、RPKI認証を有効にすると、Junos OSがTCPポート2222を自動的に開かないようになりました。
Junos OS は、IPv4 および IPv6 プレフィックスの送信元検証をサポートしています。
図1は、サンプルトポロジーを示しています。
のトポロジー例
- サポートされている標準
- Origin検証の仕組み
- ルート検証データベースとの BGP の相互作用
- RPKI検証状態をIBGPネイバーに通知するコミュニティ属性
- ノンストップのアクティブルーティングと原点検証
- プレフィックス範囲を絶対に許可されていないとしてマークする
サポートされている標準
Junos OSでのオリジン検証の実装では、以下のRFCとドラフトがサポートされています。
-
RFC 6810、 ルータープロトコルへのリソース公開キーインフラストラクチャ(RPKI)
-
RFC 6811、 BGPプレフィックス原点の検証
-
インターネットドラフトdraft-ietf-sidr-origin-validation-signaling-00、 BGPプレフィックス起点検証状態拡張コミュニティ (部分サポート)
拡張コミュニティ(起点検証状態)は、Junos OS ルーティングポリシーでサポートされています。ルート選択手順の指定変更はサポートされていません。
Origin検証の仕組み
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 レコードが存在しないため、各ルートの検証状態は不明に設定されます。
再試行期間は設定可能です。キャッシュサーバーへの接続に成功すると、ルーターは最新のデータベースシリアル番号を照会し、そのバージョンのデータベースに属するすべてのRVエントリをRPKIキャッシュに送信するように要求します。
各インバウンドメッセージは、RPKIキャッシュサーバーのライブ性タイマーをリセットします。すべての更新が学習された後、ルーターは設定可能な間隔に基づいて定期的なライブ性チェックを実行します。これは、キャッシュ サーバーが最新の通知 PDU で報告したのと同じシリアル番号を持つシリアル クエリ プロトコル データ ユニット (PDU) を送信することによって行われます。キャッシュサーバーは、ゼロ以上の更新とデータ終了(EOD)PDUで応答します。これにより、キャッシュサーバーのライブ状態も更新され、記録ライフタイムタイマーがリセットされます。
外部BGP(EBGP)ピアからプレフィックスを受信すると、インポートポリシーによって検査され、有効、無効、不明、または未確認としてマークされます。
-
有効—プレフィックスとASのペアがデータベースに存在することを示します。
-
無効—プレフィックスは見つかったが、EBGPピアから受信した対応するASがデータベースに表示されているASではないか、BGP更新メッセージのプレフィックス長がデータベースで許可されている最大長よりも長いことを示します。
-
不明—プレフィックスがデータベース内のプレフィックスまたはプレフィックス範囲にないことを示します。
-
未検証—プレフィックスの発信元がデータベースに対して検証されていないことを示します。これは、データベースにデータが入力され、BGPインポートポリシーで検証が求められていないか、送信元の検証が有効になっているか、BGPピアに対して送信元の検証が有効になっていないためです。
検証データベースにルートに一致する可能性のあるものがある場合、そのルートはそのうちの1つと一致しなければ有効になります。それ以外の場合は無効です。ルートを有効にするには、任意の一致が十分です。ベストマッチである必要はありません。一致する可能性のあるものがない場合のみ、ルートは不明と見なされます。プレフィックスからASへのマッピングデータベースロジックの詳細については、インターネットドラフトdraft-ietf-sidr-pfx-validate-01のセクション2、 BGPプレフィックス原点の検証を参照してください。
ルート検証データベースとの 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;
}
}
}
RPKI検証状態をIBGPネイバーに通知するコミュニティ属性
プレフィックス検証は、外部BGP(EBGP)アップデートに対してのみ行われます。AS内では、すべての内部BGP(IBGP)ルーターでRPKIセッションを実行しないようにすることがあります。代わりに、すべてのIBGPスピーカーが一貫した情報を持つように、IBGPメッシュ全体に検証状態を伝達する方法が必要です。これは、非推移的拡張コミュニティで検証状態を運ぶことで実現されます。コミュニティ属性は、IBGPネイバー間のプレフィックスの検証状態を通知および受信します。
Junos OSは、ルート検証のために以下の既知の拡張コミュニティをサポートしています。
-
origin-validation-state-valid
-
origin-validation-state-invalid
-
origin-validation-state-unknown
次のサンプル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レコードは、他のものと同様にインストールされ、照合されます。これにより、0は有効なASではないため、プレフィックス範囲を絶対に通知できないとしてマークする回避策が可能になりますAS。RVレコード内のASは、EBGPピアから受信したASと一致しません。したがって、一致するプレフィックスはすべて無効としてマークされます。
関連項目
BGPのオリジン検証の使用例とメリット
自律システム(AS)の管理者が、他社に割り当てられたネットワークの全部または一部のアドバタイズを開始した場合、BGPにはエラーを認識し、サービスの中断を回避する方法が組み込まれていません。
たとえば、顧客ネットワークの管理者が、トラフィックを顧客のサービスプロバイダ AS 1 に誘導するルート(たとえば 10.65.153.0/24)を誤ってアドバタイズしたとします。この/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が検証済みの場合、ポリシーでは、プレフィックスが同様にアドバタイズされるように指定できます。
要件
この例では、以下のハードウェアおよびソフトウェア要件があります。
-
サードパーティ製ソフトウェアを使用してBGPプレフィックスを認証するリソース公開鍵基盤(RPKI)キャッシュサーバー
-
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 { sessionaddress { } } }
[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ピア間でvalidation-stateコミュニティ属性を使用する例を示しています。
図4は、サンプルトポロジーを示しています。
のトポロジー
この例では、デバイスR0にはデバイスR1へのIBGP接続とデバイスR2へのEBGP接続があります。デバイスR0は、インターネットドラフトdraft-ietf-sidr-rpki-rtr-19( RPKI/ルータープロトコル )で定義されたプロトコルを使用して、キャッシュサーバーからRV(ルート検証)レコードを受信し、RVレコードを送信します。RPKIルータープロトコルはTCP上で実行されます。RV レコードは、デバイス R0 によってローカル RV データベースの構築に使用されます。デバイス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エディタの使用」を参照してください。
デバイス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ピアからインポート(または受信)されたすべてのルートに対して、validation-stateと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エディタの使用」を参照してください。
デバイス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ルートのvalidation-state 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
MultiRecv
user@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: 100
user@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