見出し画像

最も完成度の高いBGPルーティングプロトコルを詳しく解説-その5(計7)

・BGP 負荷分散

同じ宛先アドレスへの等コスト ルートが複数ある場合、BGP 等コスト ロード バランシングを使用して、トラフィックを分散するという目的を達成できます。BGP 等コスト負荷分散が成立する条件は、「BGP 経路選択戦略」のルール 1 ~ 8 で比較する属性が完全に一致することです。

ルートリフレクター(RR)

IBGP ピア間の接続を確保するには、IBGP ピア間にフルメッシュ関係を確立する必要があります。AS に n 個のデバイスがあると仮定すると、確立された IBGP 接続の数は n(n-1)/2 です。多くのデバイスがある場合、デバイス構成は非常に複雑になり、構成後のネットワーク リソースと CPU リソースの消費は非常に大きくなります。IBGP ピア間でルート リフレクタを使用すると、上記の問題を解決できます。

ルート リフレクタ関連の役割

図に示すように、ルート リフレクタには AS 内で次の役割があります。

Route Reflector : OSPF ネットワークの DR と同様に、IBGP ピアから学習したルートを他の IBGP ピアに反映できるようにする BGP デバイス。

クライアント (クライアント) : RR と反射的な近隣関係を形成する IBGP デバイス。AS 内では、クライアントは RR に直接接続するだけで済みます。

非クライアント: RR でもクライアントでもない IBGP デバイス。AS と RR 内の非クライアント間、およびすべての非クライアント間で完全な接続を確立する必要があります。

オリジネーター: AS 内でルートを開始するデバイス。Originator_ID 属性は、クラスタ内のルーティング ループを防ぐために使用されます。

クラスター (クラスター) : ルート リフレクターとそのクライアントのコレクション。Cluster_List 属性は、クラスタ間のルーティング ループを防ぐために使用されます。

ルートリフレクターの動作概要

同じクラスタ内のクライアントは、クラスタの RR とルーティング情報を直接交換するだけでよいため、クライアントは RR との IBGP 接続を確立するだけでよく、他のクライアントとの IBGP 接続を確立する必要がないため、 IBGP 接続。図に示すように、AS65000 では、1 つのデバイスが RR として機能し、3 つのデバイスがクライアントとして機能し、Cluster1 を形成します。このとき、AS65000 の IBGP 接続数は、RR 設定前の 10 から 4 に削減され、デバイス構成が簡素化されるだけでなく、ネットワークと CPU の負荷も軽減されます。

RR は、「IBGP ピアから取得した BGP ルート、BGP デバイスはその EBGP ピアにのみアドバタイズする」という制限を打ち破り、Cluster_List と Originator_ID の一意の属性を使用してルーティング ループを防ぎます。RR は、ルーティング ルールを次のように IBGP ネイバーにアドバタイズします。

  1. 非クライアントから学習したルートは、すべてのクライアントに公開されます。

  2. クライアントから学習したルートは、すべての非クライアントおよびクライアント (このルートを開始したクライアントを除く) に発行されます。

  3. EBGP ピアから学習したルートは、すべての非クライアントおよびクライアントにアドバタイズされます。

Cluster_List プロパティ

ルート リフレクタとそのクライアントは、AS 内の一意のクラスタ ID によって識別されるクラスタ (クラスタ) を形成します。クラスタ間のルーティング ループを防ぐために、ルート リフレクタは Cluster_List 属性を使用して、ルートが通過するすべてのクラスタの ClusterID を記録します。

ルートが RR によって初めて反映されるとき、RR はローカル クラスタ ID を Cluster List の先頭に追加します。Cluster_List 属性がない場合は、RR が作成します。

RR が更新されたルートを受信すると、RR は Cluster List をチェックします。Cluster List にローカル ClusterID が既に存在する場合は経路を破棄し、ローカル Cluster ID が存在しない場合は Cluster List に追加し、更新された経路を反映します。

Originator_ID プロパティ

オリジネーター ID は RR によって生成され、使用されるルーター ID の値は、クラスター内のルーティング ループを防ぐために使用されるルートのオリジネーターを識別します。

ルートが RR によって初めて反映されるとき、RR はこのルートに Originator_ID 属性を追加して、このルートの発信元デバイスを識別します。Originator_ID 属性がルートに既に存在する場合、RR は新しい Originator_ID 属性を作成してはならない。

デバイスがこのルートを受信すると、受信したオリジネーター ID とローカル ルーター ID を比較し、2 つの ID が同じ場合、このルートを受信しません。

バックアップ ルート リフレクタ

ネットワークの信頼性を高め、単一点障害がネットワークに影響を与えないようにするために、クラスタ内に複数の RR を設定する必要がある場合があります。

RR は、IBGP ピアから受信したルートを他の IBGP ピアに渡すことができないという制限を破るため、同じクラスター内の RR 間にループが存在する可能性があります。この時点で、クラスタ内のすべての RR は同じクラスタ ID を使用して、RR 間のルーティング ループを回避する必要があります。

図に示すように、ルート リフレクタ RR1 と RR2 は同じクラスタ内にあり、同じクラスタ ID で構成されています。

Client1 が EBGP ピアから更新されたルートを受信すると、IBGP を介して RR1 と RR2 にルートをアドバタイズします。

更新されたルートを受信した後、RR1 と RR2 はローカルの Cluster ID を Cluster List の先頭に追加し、他のクライアント (Client2、Client3) に反映し、同時に相互に反映します。

反映されたルートを受信した後、RR1 と RR2 は Cluster List を確認し、自分の Cluster ID が Cluster List に含まれていることを確認します。次に、RR1 と RR2 は更新されたルートを破棄し、ルーティング ループを回避します。

マルチクラスタ ルート リフレクタ

複数のクラスタが 1 つの AS に存在でき、各クラスタの RR が IBGP ピアを確立します。RR が異なるネットワーク層に配置されている場合、下位ネットワーク層の RR をクライアントとして構成して、階層型 RR を形成できます。RR が同じネットワーク層にある場合、異なるクラスター内の RR を完全に接続して、同じレベルで RR を形成できます。

実際の RR 展開では、階層型 RR のシナリオが一般的に使用されます。図に示すように、ISP は AS100 にインターネット ルーティングを提供します。AS100 は 2 つのクラスタに分割され、そのうち Cluster1 の 4 つのデバイスはコア ルータであり、信頼性を確保するためにバックアップ RR が使用されます

図に示すように、バックボーン ネットワークは複数のクラスタに分割されます。各クラスタの RR は、相互に非クライアント関係を持ち、完全な接続を確立します。この時点で、各クライアントはそれが存在するクラスタの RR とのみ IBGP 接続を確立しますが、すべての RR とクライアントはすべてのルーティング情報を受信できます。


いいなと思ったら応援しよう!