Zenn
🪞

RFC 4456: BGPルート・リフレクション: フルメッシュ内部BGP(IBGP)の代替

2024/04/19に公開
#
rfc
#
bgp
tech

本文書の位置付け

本文書は、インターネット・コミュニティのためのインターネット標準トラック・プロトコルを規定し、改善のための議論と提案を求める。このプロトコルの標準化状況とステータスについては、最新版の「インターネット公式プロトコル標準」(STD 1)を参照のこと。このメモの配布は無制限である。

著作権表示

著作権 (C) The Internet Society (2006)。

要旨

ボーダー・ゲートウェイ・プロトコル(BGP)は、TCP/IPインターネット用に設計された自律システム間ルーティング・プロトコルである。通常、一つのAS内のすべてのBGPスピーカーはフルメッシュ化されなければならず、外部のルーティング情報は自律システム(AS)内の他のすべてのルータに再配布しなければならない。これは十分に裏付けれている深刻なスケーリング問題であり、いくつかの代替案が提案されている。

本文書では、内部BGP(IBGP)の「フルメッシュ化」の必要性を軽減するために、「ルート・リフレクション」として知られる方法の使用と設計について説明する。

本文書はRFC 2796とRFC 1966を廃止する。

1. はじめに

通常、一つのAS内のすべてのBGPスピーカーはフルメッシュ化されなければならず、外部のルーティング情報はそのAS内の他のすべてのルータに再配布しなければならない。AS内のn台のBGPスピーカーの場合、\frac{n(n-1)}{2}のユニークな内部BGP(IBGP)セッションを維持する必要がある。この「フルメッシュ」要件は、今日のネットワークの多くで一般的なことだが、多数のIBGPスピーカーがそれぞれ大量のルーティング情報を交換している場合、明らかにスケールしない。

このスケーリング問題は十分に裏付けられており、これを軽減するために多くの提案が行われている[2,3]。本文書では、「ルート・リフレクション」として知られている「フルメッシュ」の必要性を軽減するもう1つの代替案を説明する。この手法は、BGPスピーカー(「ルート・リフレクタ」と呼ばれる)がIBGPで学習した経路を信頼できるIBGPピアに広告できるようにする。これは、一般に理解されているIBGPの概念の変更であり、ルーティング・アップデートのループを防ぐための、2つの新しいオプションの非推移的BGP属性の追加をあとで述べる。

本文書はRFC 2796 [6]とRFC 1966 [4]を廃止する。

2. 要件の仕様

本文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、RFC 2119 [7]の記述にしたがって解釈される。

3. 設計基準

ルート・リフレクションは、以下の基準を満たすように設計された。

  • シンプルさ

    どのような代替案であれ、設定が簡単で、理解しやすいものでなければならない。

  • 簡単な移行

    トポロジやASを変更することなく、フルメッシュ構成から移行できなければならない。これは、[3]で提案された技術の残念な管理オーバーヘッドである。

  • 互換性

    非準拠のIBGPピアが、BGPルーティング情報を失うことなく、元のASまたはドメインの一部であり続けることが可能でなければならない。

これらの基準は、多くの外部接続を持つ、非常に大規模で豊富なトポロジーのネットワークの運用経験によって動機付けられた。

4. ルート・リフレクション(経路の反射)

ルート・リフレクションの基本的な考え方は非常にシンプルである。以下の図1に示す簡単な例を考えてみる。

rfc4456-fig1
図1: フルメッシュIBGP

ASXでは、3つのIBGPスピーカー(ルータRTR-A、RTR-B、RTR-C)が存在する。既存のBGPモデルでは、RTR-Aが外部経路を受信し、それが最適パスとして選択された場合、RTR-BとRTR-Cの両方に外部経路を広告しなければならない。IBGP スピーカーであるRTR-BとRTR-Cは、これらのIBGP学習経路を他のIBGPスピーカーに再広告しない。

もし、このルールが緩和され、RTR-CがIBGPの学習経路をIBGPピアに広告できるようになったら、RTR-Aから学習したIBGP経路をRTR-Bに再広告(または反射)することができる。これにより、以下の図2に示すように、RTR-AとRTR-Bの間のIBGPセッションが不要になる。

rfc4456-fig2
図2: ルート・リフレクションIBGP

ルート・リフレクション・スキームは、この基本原理に基づいている。

5. 用語と概念

IBGPで学習した経路を別のIBGPピアに広告するBGPスピーカーの動作を表すために、「ルート・リフレクション」という用語を使う。このようなBGPスピーカーは「ルート・リフレクタ」(RR)と呼ばれ、このような経路は反射経路と呼ばれる。

RRの内部ピアは2つのグループに分けられる:

  1. クライアント・ピア
  2. 非クライアント・ピア

RRは、これらのグループ間の経路を反射し、クライアント・ピア間の経路を反射することもある。RRとそのクライアント・ピアはクラスタを形成する。非クライアント・ピアは完全にメッシュ化されていなければならないが、クライアント・ピアは完全にメッシュ化の必要はない。図3は、上記の用語を使用して、基本的なRRコンポーネントの概要を示した簡単な例である。

rfc4456-fig3
図3: RRのコンポーネント

6. オペレーション

RRはIBGPピアから経路を受信すると、パス選択ルールに基づいて最適なパスを選択する。最適なパスが選択された後、最適なパスを受信するピアのタイプに応じて以下の処理を行う必要がある。

  1. 非クライアントIBGPピアからの経路:
    すべてのクライアントに反射する。
  2. クライアント・ピアからの経路:
    すべての非クライアント・ピアに反射し、クライアント・ピアにも反射する。(したがって、クライアント・ピアは完全にメッシュ化する必要はない。)

自律システムは多くRRを持つことができる。RRは、他のRRを他の内部BGPスピーカーと同じように扱う。RRは、クライアント・グループまたは非クライアント・グループ内に他のRRを持つように構成できる。

シンプルな構成では、バックボーンを多くのクラスタに分けることができる。各RRは、他のRRを非クライアント・ピアとして設定する(したがって、すべてのRRは完全にメッシュ化される)。クライアントは、自分のクラスター内のRRとだけ、IBGPセッションを維持するように設定する。ルート・リフレクションにより、すべてのIBGPスピーカーは反射されたルーティング情報を受信する。

自律システムには、ルート・リフレクタの概念を理解していないBGPスピーカー(これを従来型BGPスピーカーと呼ぶ)が存在する可能性がある。ルート・リフレクタ・スキームは、このような従来型BGPスピーカーとの共存が可能である。従来型BGPスピーカーは、非クライアント・グループかクライアント・グループのいずれかのメンバーになることができる。これにより、現在のIBGPモデルからルート・リフレクション・モデルへの移行を簡単かつ段階的に行うことができる。1台のルータを指定RRとして設定し、他のRRとそのクライアントを通常のIBGPピアとして設定することで、クラスタを作成できる。追加のクラスタは段階的に作成できる。

⚠️ 設定例 (Cisco IOS)

以下のネットワーク構成での設定例。

rr-sample

RR1
router bgp 65000
  bgp cluster-id 100.1.1.1
  neighbor 3.3.3.3 remote-as 65000
  neighbor 3.3.3.3 update-source Loopback0
  neighbor 3.3.3.3 route-reflector-client
  neighbor 4.4.4.4 remote-as 65000
  neighbor 4.4.4.4 update-source Loopback0
  neighbor 4.4.4.4 route-reflector-client
  neighbor 2.2.2.2 remote-as 65000
  neighbor 2.2.2.2 update-source Loopback0
RR2
router bgp 65000
  bgp cluster-id 100.2.2.2
  neighbor 4.4.4.4 remote-as 65000
  neighbor 4.4.4.4 update-source Loopback0
  neighbor 4.4.4.4 route-reflector-client
  neighbor 5.5.5.5 remote-as 65000
  neighbor 5.5.5.5 update-source Loopback0
  neighbor 5.5.5.5 route-reflector-client
  neighbor 1.1.1.1 remote-as 65000
  neighbor 1.1.1.1 update-source Loopback0
R1
router bgp 65000
  bgp router-id 3.3.3.3
  network 192.168.3.0
  neighbor 1.1.1.1 remote-as 65000
  neighbor 1.1.1.1 update-source Loopback0
R2
router bgp 65000
  bgp router-id 4.4.4.4
  network 192.168.4.0
  neighbor 1.1.1.1 remote-as 65000
  neighbor 1.1.1.1 update-source Loopback0
  neighbor 2.2.2.2 remote-as 65000
  neighbor 2.2.2.2 update-source Loopback0
R3
router bgp 65000
  bgp router-id 5.5.5.5
  network 192.168.5.0
  neighbor 2.2.2.2 remote-as 65000
  neighbor 2.2.2.2 update-source Loopback0

7. 冗長RR

通常、クライアントのクラスタには1台のRRを持つ。その場合、クラスタはRRのBGP識別子で識別する。しかし、これは単一障害点となるため、同じクラスタ内に複数のRRを持つことができるようにするため、同じクラスタ内のすべてのRRを4バイトのCLUSTER_IDを設定し、RRが同じクラスタ内の他のRRからの経路を破棄できるようにする。

8. ルーティング情報のループの回避

経路が反射されると、設定ミスによって経路の再配布ループが形成される可能性がある。ルート・リフレクション方式では、ルーティング情報のループを検出・回避するために以下の属性を定義する:

ORIGINATOR_ID

ORIGINATOR_IDは、タイプコード9の新しいオプションの非推移的BGP属性である。この属性は4バイト長で、RRが経路を反射する際に作成される。この属性は、ローカルAS内の経路の発信元のBGP識別子が含まれる。ORIGINATOR_ID属性がすでに存在する場合、BGPスピーカーはORIGINATOR_ID属性を作成すべきではない(SHOULD NOT)。ORIGINATOR_ID属性を認識するルータは、BGP識別子をORIGINATOR_IDとして受信した経路を無視する必要がある(SHOULD)。

⚠️ ループ回避の説明(ORIGINATOR_ID)

loop-originator

R1とR2は異なるクラスタに属している。クライアントはEBGPで経路を受信し、それを2つのRRに送信する。その経路はRR間で反射されるが、ここでRRがクライアントから直接受信した経路よりも、RRから受信した経路を優先するポリシーを持っている場合、それがクライアントに反射され、ルーティング情報のループが発生する。

ここでは、ORIGINATOR_IDが属性が使われる。RRは経路を受信するたびに、ORIGINATOR_IDに送信元のルータのrouter-idを設定する。この場合、R1とR2は経路を受信すると、ORIGINATOR_IDをR3のrouter-idに設定する。同じアップデートを処理する可能性のある後続のRRによって、ORIGINATOR_IDは更新されることない。R3がアップデートを受信した場合、ORIGINATOR_ID属性にR3のrouter-idが含まれているため、そのアップデートを拒否する。

CLUSTER_LIST

CLUSTER_LISTは、タイプコード10の新しいオプションの非推移的BGP属性である。これは、経路が通過したリフレクション・パスを表すCLUSTER_ID値の数列である。

RRが経路を反映するとき、ローカルCLUSTER_IDをCLUSTER_LISTの先頭に付加しなければならない(MUST)。CLUSTER_LISTが空の場合は、新しいCLUSTER_LISTを作成しなければならない(MUST)。この属性を使用して、RRは設定ミスによってルーティング情報が同じクラスタにループバックしたかどうかを識別できる。CLUSTER_LISTにローカルCLUSTER_IDが見つかった場合、受信した広告は無視する必要がある(SHOULD)。

⚠️ ループ回避の説明(CLUSTER_LIST)

loop-originator

上図では、RRはルーティング情報を伝播するために、他のRRのクライアントにもなっている。そのため、ルーティング情報がループする可能性がある。RRは異なるクラスタにあるため、ORIGINATOR_IDは使えない(RRはORIGINATOR_IDを生成しない、そうしないと互いに送受信できない)。代わりに、CLUSTER_LIST属性が使われる。これは、AS-PATHに基づくループ防止メカニズムに相当する。各RRはアップデートを反射するたびに、自身のCLUSTER_IDをCLUSTER_LISTの先頭に付加する。CLUSTER_LISTに自分のCLUSTER_IDが含まれるアップデートを受信した場合、そのアップデートを拒否する。

9. 経路選択への影響

BGP決定プロセスのタイブレーク・ルール(セクション9.1.2.2、[1])は以下のように変更される:

経路がORIGINATOR_ID属性を持つ場合、ステップf)で、ORIGINATOR_IDは経路を広告したBGPスピーカーのBGP識別子として扱う必要がある(SHOULD)。

さらに、ステップf)とg)の間に次のルールを挿入する必要がある(SHOULD): BGP スピーカーは、CLUSTER_LIST長が短い経路を優先する必要がある(SHOULD)。 経路がCLUSTER_LIST属性を持たない場合、CLUSTER_LIST長はゼロになる。

10. 実装に関する考慮事項

RRは、クライアントと非クライアントの間で内部ルーティング情報を交換する際は、上記で定義されたBGPパス属性が設定によって変更できないように注意する必要がある。これらの属性が変更されると、ルーティング・ループが発生する可能性がある。

さらに、RRが経路を反射するとき、パス属性NEXT_HOP、AS_PATH、LOCAL_PREF、MEDを変更してはならない(SHOULD NOT)。これらを変更すると、ルーティング・ループが発生する可能性がある。

11. 構成と展開に関する考慮事項

BGPプロトコルでは、クライアント自身がRRクライアントであることを動的に識別する方法を提供していない。この識別を実現する最も簡単な方法は、手動設定によるものである。

スケーリング問題に対処するルート・リフレクション手法の重要なコンポーネントの1つは、ルーティング情報を要約し、その最適パスのみを反射するRRである。

Multi-Exit Discriminators (MED)と内部ゲートウェイ・プロトコル(IGP)のメトリックの両方が、BGP経路の選択に影響を与える可能性がある。MEDは必ずしも比較できるとは限らず、IGPメトリックはルータごとに異なるため、ルート・リフレクションのトポロジによっては、ルート・リフレクション手法がフルIBGPメッシュ手法と同じ経路選択結果にならないことがある。経路選択を、フルIBGPメッシュ手法と同じようにする方法は、ルート・リフレクタがクライアントのIGPメトリクスと大幅に異なるIGPメトリクスや、比較不可能なMEDに基づいて、BGP経路選択を決して強制しないことである。前者は、クラスタ内のIGPメトリクスを、クラスタ間のIGPメトリクスよりも優先度の高いものに設定し、クラスタ内でフルメッシュを維持することで実現できる。後者は以下のようにして実現できる:

  • ボーダールーターで、MED値を反映するように経路のローカル・プリファレンスを設定する、または
  • ASパスの長さを経路選択基準として使用する場合、異なるASからのASパスの長さが異なることを確認する、または
  • 経路選択に影響を与えるコミュニティ・ベースのポリシーを設定する。

しかし、後者の要件は制限が厳しすぎるため、場合によっては非現実的であると言えるだろう。さらに、ルーティング・ループがない限り、ルート・リフレクタによる経路選択をフルIBGPメッシュ手法と同じにしなければならないような、やむを得ない事情はないと言える。

ルーティング・ループを防ぎ、一貫したルーティング・ビューを維持するには、ルート・リフレクション・トポロジを設計する際にネットワーク・トポロジを慎重に考慮することが不可欠である。一般に、あるプレフィックスに対して複数のパスが存在する場合、ルート・リフレクション・トポロジはネットワーク・トポロジと一致する必要がある。一般的に使用される手法の1つは、ポイント・オブ・プレゼンス(POP)に基づくリフレクションであり、各POPがPOP内のクライアントにサービスを提供する独自のルート・リフレクタを維持し、すべてのルート・リフレクタが完全にメッシュ化される。さらに、各POPのリフレクタのクライアントは、最適なPOP内ルーティングを目的として完全にメッシュ化されることが多く、POP内IGPメトリクスはPOP間IGPメトリクスよりも優先度の高い値になるように設定する。

12. セキュリティに関する考慮事項

このBGPの拡張は、既存のIBGP[1, 5]に内在する根本的なセキュリティ問題を変更するものではない。

13. 謝辞

著者らは、この研究の結果となった多くの議論に対して、デニス・ファーガソン、ジョン・スカダー、ポール・トレイナ、トニー・リーに感謝の意を表する。このアイデアは、トニー・リーとディミトリ・ハスキンの以前の議論から発展したものである。

さらに、著者らは、本文書に関するヤコフ・レクターの貴重なレビューと提案、そしてトニー・リー、ロヒト・ドゥベ、ジョン・スカダー、ブルース・コールからの有益なコメントに感謝の意を表する。

14. 参考文献

14.1. 引用規格

[1] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

14.2. 参考規格

[2] Savola, P., "Reclassification of RFC 1863 to Historic", RFC 4223, October 2005.

[3] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065, February 2001.

[4] Bates, T. and R. Chandra, "BGP Route Reflection An alternative to full mesh IBGP", RFC 1966, June 1996.

[5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.

[6] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000.

[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

付録 A: RFC 2796 との比較

経路選択への影響を追加した。

CLUSTER_LIST属性の符号化に関する図入りの説明は、BGP仕様に対して冗長で、属性長フィールドを誤って1オクテットと記述していたため削除した。

⚠️ コメント

属性長フィールドに入る数値は、クラスタIDのオクテット数になるので、クラスタIDが1つの場合でも4オクテットになる。2つであれば、8オクテットになる。そもそも、パス属性の形式は決まっているので、改めて記載する必要もない。

付録 B: RFC 1966との比較

付録 Aに記載されているすべての変更に加えて、以下の変更が含まれる。

ルート・リフレクションに関連するいくつかの用語が明確化され、EBGP経路/ピアへの参照が削除された。

受信側による(ルート・リフレクションによる)ルーティング情報ループの扱い明確化され、一貫性が増した。

CLUSTER_LISTへのCLUSTER_IDの追加は、デプロイ済みのコードを反映するために、「追加(append)」から「先頭に追加(prepend)」に変更した。

「設定と展開に関する考慮事項」のセクションが拡張され、いくつかの運用上の問題に対応した。

著者のアドレス

トニー・ベイツ
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
メール: tbates@cisco.com

ラビ・チャンドラ
Sonoa Systems, Inc.
3255-7 Scott Blvd.
Santa Clara, CA 95054
メール: rchandra@sonoasystems.com

エンケ・チェン
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
メール: enkechen@cisco.com

完全な著作権に関する声明

著作権 (C) The Internet Society (2006)。

本文書は、BCP 78に含まれる権利、ライセンス、制限に従うものであり、そこに規定されている場合を除き、著者はすべての権利を保持する。
本文書およびここに含まれる情報は「現状のまま」で提供されるものであり、寄稿者、寄稿者が代表または後援する組織(存在する場合)、インターネット協会およびインターネット・エンジニアリング・タスク・フォースは、すべての保証を否認する。これは、明示または黙示を問わず、ここに記載された情報の使用がいかなる権利も侵害しないという保証、または商品性や特定の目的への適合性の黙示的な保証を含むが、これに限定されない。

知的財産

IETFは、本文書に記載されたテクノロジーの実装または使用に関連すると主張されうる知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスがどの程度利用可能か不可能かに関して、いかなる立場も取らない。利用可能であること。また、そのような権利を特定するために独自の努力を行ったことを表明するものでもない。RFC文書の権利に関する手続きに関する情報は、BCP 78およびBCP 79に記載されている。

IETF事務局に対して行われたIPR開示の写し、および利用可能になるライセンスの保証、または本仕様の実装者や利用者がそのような保有権の使用するための一般ライセンスや許可を取得しようとする試みの結果は、IETFのオンラインIPRリポジトリ(http://www.ietf.org/ipr) から入手できる。

IETFは、本規格の実装に必要とされる技術をカバーする著作権、特許、特許出願、その他の保有権について、利害関係者に対して注意を喚起するよう求める。情報はIETF(ietf-ipr@ietf.org)に送っていただきたい。

謝辞

RFCエディター機能の資金は、IETF Administrative Support Activity (IASA)から提供されている。

更新履歴

  • 2024.4.15
GitHubで編集を提案

Discussion