ルートサーバーの実装

Junos OS ルートサーバープラットフォーム

適切なバージョンの Junos を実行している Juniper プラットフォームは、ルートサーバーとして機能できます。しかし、ルートサーバーの導入は、多くの場合、各 EBGP クライアントのローカルリブを維持している場合があるため、BGP では通常の BGP の導入よりもわずかに多くのメモリを必要とすることがあります。その結果、通常のルーターのメモリ容量は、拡張性に優れたソリューションを提供できない場合があります。

Figure 1は、典型的な Juniper MX シリーズルーターのブロック図を示しています。

Figure 1: MX シリーズをルートサーバーとして Juniper

一般的なルーターのメモリ容量は、多くの場合、そのルーターの“対象”となる導入の役割を満たすようになっています。たとえば、コアルーター’として機能する Juniper PTX10000 シリーズは、ルートサーバーの場合と–は異なり、メモリ–要件が同じではありません。また、コアルーターに必要なラインカードやパケット転送エンジンの形式で追加ハードウェアを言及しているわけではありません。

Junos OS 仮想ルートリフレクタ (vRR)

Junos OS 仮想ルートリフレクタ (vRR) により、Junos OS 制御プレーンを導入できます。汎用の VM を使用すると、Juniper の NFX プラットフォームや Juniper JRR200 などのアプライアンスなど、64ビット Intel ベースのサーバー上で実行できます。Intel ベースのサーバーまたはアプライアンスでの vRR は、BGP を実行しているルーター上のルート re と同じように動作し、専用のハードウェアプラットフォームに代わる、拡張性とコストの高い選択肢を提供します。VRR には、以下のメリットがあります。

• 拡張性VRR が実行されるサーバーコアハードウェア (CPU とメモリ) に応じて、拡張性が向上します。

• 迅速で柔軟な導入: インテルサーバー上で実行される vRR。オープンソースツールを使用することで、典型的なルーターのメンテナンスを削減します。

Figure 2: Juniper 仮想ルートリフレクタ (vRR)

VRR プラットフォームを使用してルートサーバーを導入することで、IXP’はサーバーの CPU とメモリをターゲットの導入環境と同じにすることができます。現在のサーバープラットフォームでは、従来のルーティングエンジンに比べてコンピューティングとストレージの容量が大幅に増加しているため、ルートサーバーは、専用のルーターを超えて拡張および実行できるようになります。

Junos OS コンテナー RPD (cRPD)

前の2つの図に示されているように、rpd は Junos OS のコアコンポーネントであり、ルートの状態を学習して配信するには、さまざまなルーティングプロトコル (OSPF、ISIS、RIP、BGP、MPLS など) を実行する必要があります。コンテナ化されたrpd (crpd) は、基本 Junos OS から切り離され、Linux ベースの環境で実行できるスタンドアロンモジュールとして、rpd を支援するように設計しています。これらの環境は、独立した物理/仮想転送プレーンを備えた、ホストまたはサーバーシステム、Vm、コンテナ、ネットワークデバイスと同様にさまざまです。

また、ルートサーバーを導入するための追加オプションは、cRPD によって提供されており、vRR を使用するのとよく似たモデルになります。しかし、cRPD では、複数の rpd のインスタンスを Docker ブリッジの背後に生成することで、他にも多くの方法を紹介しています。そのため、単一のルートサーバーインスタンスが IXP クライアントに提示されますが、その背後の Docker ブリッジは rpd インスタンスのクラスターである場合があります。これにより、拡張性の向上、新しい高可用性モデル、さまざまなソフトウェアバージョン、一般的に、ルートサーバーの用途について新たに検討することが可能になります。基本的な cRPD インスタンスと、スケールアウトされたルートサーバーがどのようなものかを大まかにFigure 3示します。

Figure 3: スケールアウトされたルートサーバーとしての cRPD と cRPD

1. Https://support.juniper.net/support/downloads/からの crpd ダウンロード:
2. 構成とログ用に永続的なストレージボリュームを作成します (デフォルトサイズ: 10GB):
3. コンテナを作成して起動します。

CRPD コンテナに割り当てられるメモリと CPU の容量 (256 MB、1 CPU など) を制限するには、次のようにします。

ホスト・ネットワーキング・モードで cRPD コンテナを起動するには (共有ネットワーク名スペース (ホスト)、デフォルトでは別の名前空間):

Basic Management of cRPD

コンテナのステータスを確認しています:

アクセス cRPD CLI: JUNOS CLI を起動します。

アクセス cRPD bash シェル:

コンテナーの一時停止/再開/停止/破棄:

特定の cRPD 構成例と考慮事項については、付録 C を参照してください。

ルートサーバーの構成

以下の構成、監視、トラブルシューティングの例は、にFigure 4示す ixp ネットワーク例に基づいています。

Figure 4: IXP Network の例

Basic Junos Route-Server Client Configuration

Junos ルートの透過性をサポートするのは、標準の BGP ルートの伝達を変更して、推移性の属性や非推移性の特性がルートの伝達時に削除または変更されないようにすることです。通常の EBGP 動作の変更は、CLI 構成によって制御されます。route-server-client:

非転送型ルーティングインスタンスを使用した Junos ルートサーバーのクライアント構成

ルートサーバーのクライアント固有のリブは、同じ宛先に他のビューとは異なるルートを含めることができる BGP Loc の特徴的なビューです。ピアグループ経由のルートサーバークライアントは、1つのクライアント固有のビューまたは共有された共通のリブに関連付けることができます。

同じ宛先に対して異なるクライアントに異なるルートをアドバタイズする機能を提供するには、同じ宛先に対して複数の BGP パス選択を実行できるようにする必要があります。また、別のクライアント/グループでは、用途.

Junos OS は、非転送ルーティングインスタンスを使用して、BGP パイプラインの複数のインスタンス (BGP パス選択、Loc、ポリシーなど) を提供することで、クライアント/グループパスを選択することで柔軟なポリシー制御を実装します。Junos ルートサーバーは、個別の転送不可ルーティングインスタンス内に構成されている BGP グループ内のルートサーバークライアントをグループ化するように設定されます。このアプローチでは、ルーティングインスタンス内で実行される BGP がパス選択を行い、他のルーティングインスタンスで実行されている BGP とは異なるリブを持つという事実を活用しています。

基本的なルート/サーバークライアント構成

次の CLI の例は、IXP のメンバークライアント’ルーター s の基本構成を示しています。ご覧’のように、ルートサーバーの設定と比較した場合、クライアントは、必要なコミュニティで ixp で提供するルートにタグを付けるだけで、ルートサーバーは残りを実行することになります。その理由はシンプルではありません。

この例では、’C1’s ポリシーがオープンで、すべての ixp メンバーにプリフィックスを提供できるようにします。したがって、標準 BGP コミュニティー64496:123 を、すべての広告プリフィックスに添付してみましょう。

しかし、’C2 のピアリングポリシーは、その接頭辞が C1 にのみアドバタイズされるということを規定していますが、他のユーザーには提供していません。その接頭辞は BGP 標準コミュニティーによってアドバタイズされます。64497:64496 は、ルートサーバーが、インスタンスインポートを’C1 のルーティングインスタンスのみに制限することを示しています。

デフォルト EBGP ルートの伝播動作 (ポリシーなし) (RFC8212)

Junos OS はまだ RFC8212 (https://tools.ietf.org/html/rfc8212) をネイティブでサポートしていません。そのため、slax スクリプトが利用可能になり、この動作を実現するために使用する必要があります。

Rfc8212 は、エクスポートポリシーが存在しない場合、RFC8212 実装の欠落を deny all ステートメントで置き換える厳格な実装です。

ポリシーの緩やかな形式は次の場所にあります。https://github.com/packetsource/rfc8212-Junos.

以下の設定変更を適用します。

汎用 TTL セキュリティーメカニズム (RFC3682)

汎用的な TTL セキュリティーメカニズム (GTSM) は、ルーター’の IP ベースの制御プレーンを CPU の使用率ベースの攻撃から保護するように設計されています。GTSM は、分離されたルーター間で多くのプロトコル peerings を確立しているという事実に基づいています。これは、IX LAN 上の EBGP ピアの場合と同様です。TTL スプーフィングは非常に不可能であるため、予想される TTL 値に基づくメカニズムは、ネットワーク外部からのプロトコルパケットに基づいて、シンプルで合理的なインフラストラクチャ攻撃からの防御を実現できます。

最大プレフィックス数制限

BGP prefix-limit機能により、BGP の近傍から受信可能なプリフィックスの数を制御できます。プレフィックス制限機能は、クライアントルーターが、以前に合意した数を超えるルートサーバーからのプレフィックスを受け付けないようにする場合に便利です。これにより、IXP のメンバーによって故意または意図せずルーターサーバーの過負荷を防ぐことができます。

または、ルートサーバーを設定して、IXP メンバーから受け付けるプレフィックス数を制限することもできます。これは、入力プレフィックスの検証が IXP によってどのように処理されるかによって、有用であるかどうかによって異なります。たとえば、無効なルートが破棄された場合、受け入れられるプレフィックスの数がアドバタイズしたプレフィックスの数と異なる場合があります。

ローカルリブインポート/エクスポートポリシーの設定例

ルートサーバーのクライアント間でルートを伝達するには、構成されたポリシーや適切に定義されたコミュニティー値に基づいて、ルーティングインスタンスの突起部分の間でルートをリークする必要があります。N 個のクライアント専用ルーティングインスタンス間でのルートリークの完全なメッシュを構成します。 instance-importや instance修飾子には n 個のテーブル固有のポリシーが必要です。各ポリシーには、1つの項目を使用して、メモリリークが発生するルーティングインスタンスの名前を明示的に指定します。そのため、ポリシー設定は O (n ^ 2) の順序で急増します。

構成の便宜として、 instance-anyポリシー修飾子は、使用できるように提供されています。 instance-importポリシ. こちらの instance-any修飾子には、他のすべてのルーティングインスタンスからルートをリークするための機能が含まれています。 instance-importが設定されています。こちらの instance-importその他の条件に基づいて、IXP グローバルコミュニティポリシーに適合する追加のフィルタリングを実装することもできます。

さらに、次に説明するルーティングポリシーの例は、『 Figure 5Internet Exchange Point Overview』で説明されているワークフローに従っています。ワークフローは、クライアント C1 からルートサーバーへのアナウンスされたルートと、その後クライアント C2 にたどります。

Figure 5: ルートサーバーの構成例ワークフロー

インスタンスインポートポリシーの例

1’つ目の製品を使用する方法を見てみましょう instance-anyオープンルーティングポリシーを持つすべてのルーティングインスタンスからルートをインポートするために、フィルタに一致する標準コミュニティーとともにポリシーの修飾子を使用します。

ポリシー用語が最初に使用する方法を確認することができます。 instance-anyこの例では、オープンポリシー用の IXP グローバルコミュニティを表すコミュニティー64511:111 と一致しています。次に、そのポリシーが適用されます。 routing-instance instance-import接続ポイント:

このセクションの冒頭で alluded として、インスタンスのサブセットを設定する別の方法として、 instance-listid. 次の例は、インスタンス-any 修飾子を使用する代わりに、個々のクライアントルーティングインスタンスとコミュニティ値 0:100 (IXP グローバルコミュニティ) を示しており、特定のルートサーバークライアントへのルーティング通知をブロックしています。

インポートポリシーの例

この例では、前述のプレフィックス検証セクションで説明されているように、IRR オブジェクト検証に基づいた有効/無効なコミュニティー値を持つプレフィックスを受け入れてタグ付けします。いくつかの例では、後のセクションで説明したように、サードパーティ製ツールを活用して自動的に構築できます。route-filter-listおよび as-path-group一覧. このポリシー例では、後のインスタンスインポート/エクスポートポリシーで使用されるコミュニティータグを追加します。

BGP の発生元検証の例 (RPKI)

明示的を作成して管理するための代替手段 as-path-groupおよび route-filter-listこのガイドで前述したように、RPKI を使用することをリストしています。以下のポリシーは、RPKI 検証データベースをチェックし、返された検証コミュニティーを使用して宛先をマークします。 valid、 invalid、または unknown:

ここで示されているコミュニティーの形式は、RFC8097 セクション2の結果を示しています。ここでは、拡張タイプフィールドの上位オクテットの値が0x43 で、これが非推移性であることが示されています。IANA によって割り当てられる、[拡張タイプ] フィールドの下位オクテットの値は0x00 です。さらに、拡張コミュニティーの最後のオクテットは、ルート’の検証状態に以下の値を付与する符号なし整数です。

• 0 = ルックアップ結果 = 有効

• 1 = ルックアップ結果 = 見つかりませんでした

• 2 = ルックアップ結果 = 無効

ルーティングインスタンスのエクスポートポリシーの例

次のインスタンスエクスポートポリシーの例では、RPKI データベースルックアップによって無効としてマークされているプレフィックスを拒否します。 route-filter-listミス、 as-path-group miss。その他のすべての接頭辞は、次にインスタンスインポートポリシーによってチェックされます。

エクスポートポリシーの例

ほとんどの場合、ポリシーは、インポートポリシー、インスタンス-エクスポートポリシー、およびインスタンスインポートポリシーの間にすでに実装されています。残りの唯一のポリシーでは、ルートサーバーのクライアントに接頭辞を送信する前にプレフィックス検証コミュニティを削除することができます。これには、有効/無効/未知のコミュニティーも含まれる場合があります。上記の RPKI ポリシーの例は、RPKI が無効なプレフィクスをドロップしているという、非常に厳格なポリシーです。 instance-export。IXP ポリシーは、単に結果をサービスとして IXP のメンバーに渡すことができるため、検証結果の使用方法を決定することができます。