[要約] 要約：RFC 3345は、BGPの持続的な経路振動状態に関する問題を説明しています。 目的：このRFCの目的は、BGPネットワークでの経路振動を理解し、その原因と解決策を提供することです。
Network Working Group D. McPherson
Request for Comments: 3345 TCB
Category: Informational V. Gill
AOL Time Warner, Inc.
D. Walton
A. Retana
Cisco Systems, Inc.
August 2002
Border Gateway Protocol (BGP) Persistent Route Oscillation Condition
境界ゲートウェイプロトコル（BGP）永続的なルート振動条件
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
In particular configurations, the BGP scaling mechanisms defined in "BGP Route Reflection - An Alternative to Full Mesh IBGP" and "Autonomous System Confederations for BGP" will introduce persistent BGP route oscillation. This document discusses the two types of persistent route oscillation that have been identified, describes when these conditions will occur, and provides some network design guidelines to avoid introducing such occurrences.
特定の構成では、「BGPルートリフレクション - フルメッシュIBGPの代替」および「BGPの自律システムコンフェデレーション」で定義されたBGPスケーリングメカニズムは、持続的なBGPルート振動を導入します。このドキュメントでは、特定された2種類の永続的なルート振動について説明し、これらの条件がいつ発生するかを説明し、そのような発生の導入を避けるためのネットワーク設計ガイドラインを提供します。
The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems.
Border Gateway Protocol（BGP）は、自律システム間ルーティングプロトコルです。BGPスピーキングシステムの主な機能は、他のBGPシステムとネットワークリーチ性情報を交換することです。
In particular configurations, the BGP [1] scaling mechanisms defined in "BGP Route Reflection - An Alternative to Full Mesh IBGP" [2] and "Autonomous System Confederations for BGP" [3] will introduce persistent BGP route oscillation.
特定の構成では、「BGPルート反射 - フルメッシュIBGPの代替」[2]および「BGPの自律システムコンフェデレーション」[3]で定義されたBGP [1]スケーリングメカニズムは、持続的なBGPルート振動を導入します。
The problem is inherent in the way BGP works: locally defined routing policies may conflict globally, and certain types of conflicts can cause persistent oscillation of the protocol. Given current practices, we happen to see the problem manifest itself in the context of MED + route reflectors or confederations.
この問題は、BGPの仕組みに固有のものです。ローカルで定義されたルーティングポリシーはグローバルに競合する可能性があり、特定の種類の競合がプロトコルの持続的な振動を引き起こす可能性があります。現在の慣行を考えると、問題がMEDルートリフレクターまたはコンフェデレーションのコンテキストで現れていることがわかりました。
The current specification of BGP-4 [4] states that the MULTI_EXIT_DISC is only comparable between routes learned from the same neighboring AS. This limitation is consistent with the description of the attribute: "The MULTI_EXIT_DISC attribute may be used on external (inter-AS) links to discriminate among multiple exit or entry points to the same neighboring AS." [1,4]
BGP-4 [4]の現在の仕様は、Multi_Exit_Discは、同じ隣接から学習したルート間でのみ匹敵することを示しています。この制限は、属性の説明と一致しています。「Multi_exit_disc属性は、外部（inter-as）リンクで使用して、同じ隣接する複数の出口またはエントリポイントを区別することができます。」[1,4]
In a full mesh iBGP network, all the internal routers have complete visibility of the available exit points into a neighboring AS. The comparison of the MULTI_EXIT_DISC for only some paths is not a problem.
フルメッシュIBGPネットワークでは、すべての内部ルーターが使用可能な出口ポイントを隣接するASに完全に可視化します。一部のパスのみのMulti_Exit_Discの比較は問題ではありません。
Because of the scalability implications of a full mesh iBGP network, two alternatives have been standardized: route reflectors [2] and AS confederations [3]. Both alternatives describe methods by which route distribution may be achieved without a full iBGP mesh in an AS.
フルメッシュIBGPネットワークのスケーラビリティへの影響により、ルートリフレクター[2]とコンフェデレーション[3]の2つの選択肢が標準化されています。どちらの代替手段も、ASの完全なIBGPメッシュなしでルート分布を達成できる方法を説明しています。
The route reflector alternative defines the ability to re-advertise (reflect) iBGP-learned routes to other iBGP peers once the best path is selected [2]. AS Confederations specify the operation of a collection of autonomous systems under a common administration as a single entity (i.e. from the outside, the internal topology and the existence of separate autonomous systems are not visible). In both cases, the reduction of the iBGP full mesh results in the fact that not all the BGP speakers in the AS have complete visibility of the available exit points into a neighboring AS. In fact, the visibility may be partial and inconsistent depending on the location (and function) of the router in the AS.
ルートリフレクターの代替は、最適なパスが選択されたら、他のIBGPピアへのIBGP学習ルートを再承認（反映する）機能を定義します[2]。南軍が単一のエンティティとして共通の管理下での自律システムのコレクションの運用を指定しているため（つまり、外部から、内部トポロジと個別の自律システムの存在は見えません）。どちらの場合も、IBGPフルメッシュの削減により、ASのすべてのBGPスピーカーが隣接するASに完全に視認されるわけではないという事実が得られます。実際、ASのルーターの位置（および関数）に応じて、可視性は部分的で一貫性がありません。
In certain topologies involving either route reflectors or confederations (detailed description later in this document), the partial visibility of the available exit points into a neighboring AS may result in an inconsistent best path selection decision as the routers don't have all the relevant information. If the inconsistencies span more than one peering router, they may result in a persistent route oscillation. The best path selection rules applied in this document are consistent with the current specification [4].
ルートリフレクターまたはコンフェデレーションのいずれかを含む特定のトポロジ（このドキュメントの後半の詳細な説明）では、ルーターがすべての関連情報を持っていないため、一貫性のない最良のパス選択決定をもたらす可能性があるため、利用可能な出口ポイントの部分的な可視性が隣接する可能性があるため、。矛盾が複数のピアリングルーターに及ぶ場合、それらは持続的なルート振動をもたらす可能性があります。このドキュメントに適用される最良のパス選択ルールは、現在の仕様と一致しています[4]。
The persistent route oscillation behavior is deterministic and can be avoided by employing some rudimentary BGP network design principles until protocol enhancements resolve the problem.
持続的なルート振動挙動は決定論的であり、プロトコルの強化が問題を解決するまで、いくつかの基本的なBGPネットワーク設計原則を採用することで回避できます。
In the following sections a taxonomy of the types of oscillations is presented and a description of the set of conditions that will trigger route oscillations is given. We continue by providing several network design alternatives that remove the potential of this occurrence.
次のセクションでは、振動の種類の分類法が提示され、ルート振動をトリガーする一連の条件の説明が示されています。この発生の可能性を削除するいくつかのネットワーク設計の代替品を提供することで継続します。
It is the intent of the authors that this document serve to increase operator awareness of the problem, as well as to trigger discussion and subsequent proposals for potential protocol enhancements that remove the possibility of this to occur.
このドキュメントが、問題に対するオペレーターの認識を高めるのに役立つのは著者の意図です。また、この発生の可能性を排除する潜在的なプロトコル強化の議論とその後の提案を引き起こすことです。
The oscillations are classified into Type I and Type II depending upon the criteria documented below.
振動は、以下に文書化された基準に応じて、タイプIおよびタイプIIに分類されます。
In the following two subsections we provide configurations under which Type I Churn will occur. We begin with a discussion of the problem when using Route Reflection, and then discuss the problem as it relates to AS Confederations.
次の2つのサブセクションでは、タイプIチャーンが発生する構成を提供します。ルートリフレクションを使用する際の問題の議論から始めて、それがコンフェデレーションと関連する問題について議論します。
In general, Type I Churn occurs only when BOTH of the following conditions are met:
一般に、タイプIチャーンは、次の両方の条件が満たされた場合にのみ発生します。
1) a single-level Route Reflection or AS Confederations design is used in the network AND
1) シングルレベルのルートリフレクションまたはコンフェデレーションデザインがネットワークで使用され、
2) the network accepts the BGP MULTI_EXIT_DISC (MED) attribute from two or more ASs for a single prefix and the MED values are unique.
2) ネットワークは、単一のプレフィックスに対して2つ以上のASSからBGP Multi_exit_disc（MED）属性を受け入れ、MED値は一意です。
It is also possible for the non-deterministic ordering of paths to cause the route oscillation problem. [1] does not specify that paths should be ordered based on MEDs but it has been proven that non-deterministic ordering can lead to loops and inconsistent routing decisions. Most vendors have either implemented deterministic ordering as default behavior, or provide a knob that permits the operator to configure the router to order paths in a deterministic manner based on MEDs.
また、パスの非決定的な順序がルート振動の問題を引き起こす可能性もあります。[1]は、PATHをMEDに基づいて秩序化する必要があることを指定していませんが、非決定的秩序はループや一貫性のないルーティングの決定につながる可能性があることが証明されています。ほとんどのベンダーは、デフォルトの動作として決定論的順序を実装するか、オペレーターがMEDに基づいて決定論的な方法でパスを注文するようにオペレーターを構成できるノブを提供しています。
We now discuss Type I oscillation as it relates to Route Reflection. To begin, consider the topology depicted in Figure 1:
ルートリフレクションに関連するタイプI振動について説明します。まず、図1に描かれているトポロジを考えてみましょう。
---------------------------------------------------------------
/ -------------------- -------------------- \
| / \ / \ |
| | Cluster 1 | | Cluster 2 | |
| | | | | |
| | | *1 | | |
| | Ra(RR) . . . . . . . . . . . . . . Rd(RR) | |
| | . . | | . | |
| | .*5 .*4 | | .*12 | |
| | . . | | . | |
| | Rb(C) Rc(C) | | Re(C) | |
| | . . | | . | |
| \ . . / \ . / |
| ---.------------.--- ---------.---------- |
\ .(10) .(1) AS1 .(0) /
-------.------------.---------------------------.--------------
. . .
------ . ------------ .
/ \ . / \ .
| AS10 | | AS6 |
\ / \ /
------ ------------
. .
. .
. --------------
. / \
| AS100 |- 10.0.0.0/8
\ /
--------------
Figure 1: Example Route Reflection Topology
図1：ルート反射トポロジの例
In Figure 1 AS1 contains two Route Reflector Clusters, Clusters 1 and 2. Each Cluster contains one Route Reflector (RR) (i.e., Ra and Rd, respectively). An associated 'RR' in parentheses represents each RR. Cluster 1 contains two RR Clients (Rb and Rc), and Cluster 2 contains one RR Client (Re). An associated 'C' in parentheses indicates RR Client status. The dotted lines are used to represent BGP peering sessions.
図1には、AS1には2つのルートリフレクタークラスター、クラスター1と2が含まれています。各クラスターには、1つのルートリフレクター（RR）（つまり、RAとRD）が含まれています。括弧内の関連する「RR」は、各RRを表します。クラスター1には2つのRRクライアント（RBとRC）が含まれ、クラスター2には1つのRRクライアント（RE）が含まれています。括弧内の関連する「C」は、RRクライアントのステータスを示します。点線は、BGPピアリングセッションを表すために使用されます。
The number contained in parentheses on the AS1 EBGP peering sessions represents the MED value advertised by the peer to be associated with the 10.0.0.0/8 network reachability advertisement.
AS1 EBGPピアリングセッションの括弧内に含まれる数は、10.0.0.0/8のネットワークリーチビリティ広告に関連するようにピアが宣伝するMED値を表しています。
The number following each '*' on the IBGP peering sessions represents the additive IGP metrics that are to be associated with the BGP NEXT_HOP attribute for the concerned route. For example, the Ra IGP metric value associated with a NEXT_HOP learned via Rb would be 5; while the metric value associated with the NEXT_HOP learned via Re would be 13.
IBGPピアリングセッションの各「*」に続く数は、関係ルートのBGP Next_Hop属性に関連付けられる追加のIGPメトリックを表します。たとえば、RBを介して学習したnext_hopに関連付けられたRA IGPメトリック値は5です。REを介して学習したnext_hopに関連付けられたメトリック値は13です。
Table 1 depicts the 10.0.0.0/8 route attributes as seen by routers Rb, Rc and Re, respectively. Note that the IGP metrics in Figure 1 are only of concern when advertising the route to an IBGP peer.
表1は、ルーターRB、RC、およびREでそれぞれ見られる10.0.0.0/8ルート属性を示しています。図1のIGPメトリックは、IBGPピアへのルートを宣伝する場合にのみ懸念されることに注意してください。
Router MED AS_PATH
--------------------
Rb 10 10 100
Rc 1 6 100
Re 0 6 100
Table 1: Route Attribute Table
表1：ルート属性テーブル
For the following steps 1 through 5, the best path will be marked with a '*'.
次の手順1〜5について、最適なパスには「*」でマークされます。
1) Ra has the following installed in its BGP table, with the path learned via AS2 marked best:
1) RAには、次のBGPテーブルにインストールされており、AS2を介して学習したパスが最適になりました。
NEXT_HOP
AS_PATH MED IGP Cost
-----------------------
6 100 1 4
* 10 100 10 5
The '10 100' route should not be marked as best, though this is not the cause of the persistent route oscillation. Ra realizes it has the wrong route marked as best since the '6 100' path has a lower IGP metric. As such, Ra makes this change and advertises an UPDATE message to its neighbors to let them know that it now considers the '6 100, 1, 4' route as best.
これは永続的なルート振動の原因ではありませんが、「10 100」ルートを最適にマークするべきではありません。RAは、「6 100」パスのIGPメトリックが低いため、間違ったルートが最適であるとマークされていることを認識しています。そのため、Raはこの変更を行い、近隣諸国に更新メッセージを宣伝し、「6 100、1、4」ルートを最高と見なしていることを知らせます。
2) Rd receives the UPDATE from Ra, which leaves Rd with the following installed in its BGP table:
2) RDはRAからアップデートを受け取ります。RAからBGPテーブルに次のようにインストールされた状態でRDが残ります。
NEXT_HOP
AS_PATH MED IGP Cost
-----------------------
* 6 100 0 12
6 100 1 5
Rd then marks the '6 100, 0, 12' route as best because it has a lower MED. Rd sends an UPDATE message to its neighbors to let them know that this is the best route.
その後、RDは、測定値が低いため、「6 100、0、12」ルートを最適にマークします。RDは、隣人に更新メッセージを送信して、これが最良のルートであることを知らせます。
3) Ra receives the UPDATE message from Rd and now has the following in its BGP table:
3) RAはRDから更新メッセージを受信し、BGPテーブルに次のようになりました。
NEXT_HOP
AS_PATH MED IGP Cost
-----------------------
6 100 0 13
6 100 1 4
* 10 100 10 5
The first route (6 100, 0, 13) beats the second route (6 100, 1, 4) because of a lower MED. Then the third route (10 100, 10, 5) beats the first route because of lower IGP metric to NEXT_HOP. Ra sends an UPDATE message to its peers informing them of the new best route.
最初のルート（6 100、0、13）は、メッドが低いため、2番目のルート（6 100、1、4）を打ち負かします。次に、3番目のルート（10 100、10、5）は、IGPメトリックがnext_hopに低いため、最初のルートを打ち負かします。RAは、新しい最高のルートを通知する更新メッセージを同僚に送信します。
4) Rd receives the UPDATE message from Ra, which leaves Rd with the following BGP table:
4) RDはRAから更新メッセージを受信します。RAは、次のBGPテーブルをRDに残します。
NEXT_HOP
AS_PATH MED IGP Cost
-----------------------
6 100 0 12
* 10 100 10 6
Rd selects the '10 100, 10, 6' path as best because of the IGP metric. Rd sends an UPDATE/withdraw to its peers letting them know this is the best route.
RDは、IGPメトリックのために'10 100、10、6 'パスを最適に選択します。RDは、これが最良のルートであることを知らせるために、同僚に更新/撤回を送信します。
5) Ra receives the UPDATE message from Rd, which leaves Ra with the following BGP table:
5) RAはRDから更新メッセージを受信します。RDは、RAに次のBGPテーブルを残します。
NEXT_HOP
AS_PATH MED IGP Cost
-----------------------
6 100 1 4
* 10 100 10 5
Ra received an UPDATE/withdraw for '6 100, 0, 13', which changes what is considered the best route for Ra. This is why Ra has the '10 100, 10, 5' route selected as best in Step 1, even though '6 100, 1, 4' is actually better.
RAは、 '6 100、0、13'の更新/引き出しを受け取りました。これは、RAにとって最適なルートと見なされるものを変更します。これが、「6 100、1、4」が実際に優れているにもかかわらず、ステップ1で最適な'10 100、10、5 'ルートを持っている理由です。
At this point, we've made a full loop and are back at Step 1. The router realizes it is using the incorrect best path, and repeats the cycle. This is an example of Type I Churn when using Route Reflection.
この時点で、フルループを作成し、ステップ1に戻りました。ルーターは、誤った最良のパスを使用していることに気付き、サイクルを繰り返します。これは、ルートリフレクションを使用する場合のタイプIチャーンの例です。
Now we provide an example of Type I Churn occurring with AS Confederations. To begin, consider the topology depicted in Figure 2:
次に、コンフェデレーションとして発生するタイプIチャーンの例を提供します。まず、図2に描かれているトポロジを考えてみましょう。
---------------------------------------------------------------
/ -------------------- -------------------- \
| / \ / \ |
| | Sub-AS 65000 | | Sub-AS 65001 | |
| | | | | |
| | | *1 | | |
| | Ra . . . . . . . . . . . . . . . . . Rd | |
| | . . | | . | |
| | .*3 .*2 | | .*6 | |
| | . . | | . | |
| | Rb . . . . . Rc | | Re | |
| | . *5 . | | . | |
| \ . . / \ . / |
| ---.------------.--- ---------.---------- |
\ .(10) .(1) AS1 .(0) /
-------.------------.---------------------------.--------------
. . .
------ . ------------ .
/ \ . / \ .
| AS10 | | AS6 |
\ / \ /
------ ------------
. .
. .
. --------------
. / \
| AS100 |- 10.0.0.0/8
\ /
--------------
Figure 2: Example AS Confederations Topology
図2：コンフェデレーショントポロジーとしての例
The number contained in parentheses on each AS1 EBGP peering session represents the MED value advertised by the peer to be associated with the 10.0.0.0/8 network reachability advertisement.
各AS1 EBGPピアリングセッションの括弧内に含まれる数は、10.0.0.0/8のネットワークリーチビリティ広告に関連付けられるようにピアが宣伝するMED値を表しています。
The number following each '*' on the IBGP peering sessions represents the additive IGP metrics that are to be associated with the BGP NEXT_HOP attribute for the concerned route.
IBGPピアリングセッションの各「*」に続く数は、関係ルートのBGP Next_Hop属性に関連付けられる追加のIGPメトリックを表します。
For example, the Ra IGP metric value associated with a NEXT_HOP learned via Rb would be 3; while the metric value associated with the NEXT_HOP learned via Re would be 6.
たとえば、RBを介して学習したnext_hopに関連付けられたRA IGPメトリック値は3です。REを介して学習したnext_hopに関連付けられたメトリック値は6です。
Table 2 depicts the 10.0.0.0/8 route attributes as seen by routers Rb, Rc and Re, respectively. Note that the IGP metrics in Figure 2 are only of concern when advertising the route to an IBGP peer.
表2は、ルーターRB、RC、およびREでそれぞれ見られる10.0.0.0/8ルート属性を示しています。図2のIGPメトリックは、IBGPピアへのルートを宣伝する場合にのみ懸念されることに注意してください。
Router MED AS_PATH
--------------------
Rb 10 10 100
Rc 1 6 100
Re 0 6 100
Table 2: Route Attribute Table
表2：ルート属性テーブル
For the following steps 1 through 6 the best route will be marked with an '*'.
次の手順1〜6では、最適なルートには「*」でマークされます。
1) Ra has the following BGP table:
1) RAには次のBGPテーブルがあります。
NEXT_HOP
AS_PATH MED IGP Cost
-------------------------------
* 10 100 10 3
(65001) 6 100 0 7
6 100 1 2
The '10 100' route is selected as best and is advertised to Rd, though this is not the cause of the persistent route oscillation.
「10 100」ルートは最適に選択され、RDに宣伝されていますが、これは永続的なルート振動の原因ではありません。
2) Rd has the following in its BGP table:
2) RDには、BGPテーブルに次のものがあります。
NEXT_HOP
AS_PATH MED IGP Cost
-------------------------------
6 100 0 6
* (65000) 10 100 10 4
The '(65000) 10 100' route is selected as best because it has the lowest IGP metric. As a result, Rd sends an UPDATE/withdraw to Ra for the '6 100' route that it had previously advertised.
'（65000）10 100'ルートは、最も低いIGPメトリックを持つため、最適に選択されます。その結果、RDは、以前に宣伝していた「6 100」ルートの更新/RAへの撤回を送信します。
3) Ra receives the withdraw from Rd. Ra now has the following in its BGP table:
3) RAはRdからの撤退を受け取ります。RAはBGPテーブルに次のようになりました。
NEXT_HOP
AS_PATH MED IGP Cost
-------------------------------
* 10 100 10 3
6 100 1 2
Ra received a withdraw for '(65001) 6 100', which changes what is considered the best route for Ra. Ra does not compute the best path for a prefix unless its best route was withdrawn. This is why Ra has the '10 100, 10, 3' route selected as best, even though the '6 100, 1, 2' route is better.
RAは、 '（65001）6 100'の撤回を受けました。これは、RAにとって最適なルートと見なされるものを変更します。RAは、最適なルートが撤回されない限り、プレフィックスに最適なパスを計算しません。これが、RAが「6 100、1、2」ルートの方が優れているにもかかわらず、'10 100、10、3 'ルートを最適に選択している理由です。
4) Ra's periodic BGP scanner runs and realizes that the '6 100' route is better because of the lower IGP metric. Ra sends an UPDATE/withdraw to Rd for the '10 100' route since Ra is now using the '6 100' path as its best route.
4) RAの周期的なBGPスキャナーは、IGPメトリックが低いため、「6 100」ルートの方が優れていることを認識しています。RAは、「6 100」パスを最適なルートとして使用しているため、「10 100」ルートのために更新/撤退をRDに送信します。
Ra's BGP table looks like this:
RAのBGPテーブルは次のようになります：
NEXT_HOP
AS_PATH MED IGP Cost
-------------------------------
10 100 10 3
* 6 100 1 2
5) Rd receives the UPDATE from Ra and now has the following in its BGP table:
5) RDはRAからアップデートを受け取り、BGPテーブルに次のようになりました。
NEXT_HOP
AS_PATH MED IGP Cost
-------------------------------
(65000) 6 100 1 3
* 6 100 0 6
Rd selects the '6 100, 0, 6' route as best because of the lower MED value. Rd sends an UPDATE message to Ra, reporting that '6 100, 0, 6' is now the best route.
RDは、低い医療値のために「6 100、0、6」ルートを最適に選択します。RDはRAに更新メッセージを送信し、 '6 100、0、6'が最適なルートであると報告しています。
6) Ra receives the UPDATE from Rd. Ra now has the following in its BGP table:
6) RAはRdからアップデートを受け取ります。RAはBGPテーブルに次のようになりました。
NEXT_HOP
AS_PATH MED IGP Cost
-------------------------------
* 10 100 10 3
(65001) 6 100 0 7
6 100 1 2
At this point we have made a full cycle and are back to step 1. This is an example of Type I Churn with AS Confederations.
この時点で、私たちは完全なサイクルを作成し、ステップ1に戻りました。これは、同盟としてのタイプIチャーンの例です。
There are a number of alternatives that can be employed to avoid this problem:
この問題を回避するために採用できる多くの選択肢があります。
1) When using Route Reflection make sure that the inter-Cluster links have a higher IGP metric than the intra-Cluster links. This is the preferred choice when using Route Reflection. Had the inter-Cluster IGP metrics been much larger than the intra-Cluster IGP metrics, the above would not have occurred.
1) ルートリフレクションを使用する場合、クラスター間リンクがクラスター内リンクよりも高いIGPメトリックを持っていることを確認してください。これは、ルートリフレクションを使用する場合の好ましい選択です。クラスター間のIGPメトリックがクラスター内のIGPメトリックよりもはるかに大きかった場合、上記は発生しなかったでしょう。
2) When using AS Confederations ensure that the inter-Sub-AS links have a higher IGP metric than the intra-Sub-AS links. This is the preferred option when using AS Confederations. Had the inter-Sub-AS IGP metrics been much larger than the intra-Sub-AS IGP metrics, the above would not have occurred.
2) コンフェデレーションとして使用する場合、インターサブとしてのリンクが、サブ内としてのリンクよりも高いIGPメトリックを持つことを保証します。これは、コンフェデレーションとして使用する場合の好ましいオプションです。IGPメトリックとしてのSub-inter-Sub-sub-sub-intra-sub-as IGPメトリックよりもはるかに大きかった場合、上記は発生していませんでした。
3) Do not accept MEDs from peers (this may not be a feasible alternative).
3) 仲間からの薬を受け入れないでください（これは実現可能な代替手段ではないかもしれません）。
4) Utilize other BGP attributes higher in the decision process so that the BGP decision algorithm never reaches the MED step. As using this completely overrides MEDs, Option 3 may make more sense.
4) BGP決定アルゴリズムがMEDステップに到達しないように、決定プロセスで他のBGP属性をより高く利用します。これを使用することは完全に無効になるため、オプション3はより意味があります。
5) Always compare BGP MEDs, regardless of whether or not they were obtained from a single AS. This is probably a bad idea since MEDs may be derived in a number of ways, and are typically done so as a matter of operator-specific policy. As such, comparing MED values for a single prefix learned from multiple ASs is ill-advised. Of course, this mostly defeats the purpose of MEDs, and as such, Option 3 may be a more viable alternative.
5) BGP MEDを単一から取得したかどうかに関係なく、常に比較してください。MEDはさまざまな方法で導き出される可能性があり、通常、オペレーター固有のポリシーの問題として行われるため、これはおそらく悪い考えです。そのため、複数のお尻から学習した単一のプレフィックスのMED値を比較することは賢明ではありません。もちろん、これは主に薬の目的を打ち負かし、そのため、オプション3はより実行可能な代替手段かもしれません。
6) Use a full IBGP mesh. This is not a feasible solution for ASs with a large number of BGP speakers.
6) 完全なIBGPメッシュを使用します。これは、多数のBGPスピーカーを備えたASSの実行可能なソリューションではありません。
In the following subsection we provide configurations under which Type II Churn will occur when using AS Confederations. For the sake of brevity, we avoid similar discussion of the occurrence when using Route Reflection.
次のサブセクションでは、コンフェデレーションとして使用するときにタイプIIチャーンが発生する構成を提供します。簡潔にするために、ルートリフレクションを使用する際の発生に関する同様の議論を避けます。
In general, Type II churn occurs only when BOTH of the following conditions are met:
一般に、タイプIIチャーンは、次の両方の条件が満たされた場合にのみ発生します。
1) More than one tier of Route Reflection or Sub-ASs is used in the network AND
1) ルートリフレクションまたはサブアスの複数の層がネットワークで使用され、
2) the network accepts the BGP MULTI_EXIT_DISC (MED) attribute from two or more ASs for a single prefix and the MED values are unique.
2) ネットワークは、単一のプレフィックスに対して2つ以上のASSからBGP Multi_exit_disc（MED）属性を受け入れ、MED値は一意です。
Let's now examine the occurrence of Type II Churn as it relates to AS Confederations. Figure 3 provides our sample topology:
次に、コンフェデレーションに関連するタイプIIチャーンの発生を調べましょう。図3にサンプルトポロジーを示します。
---------------------------------------------------------------
/ ------------------- \
| AS 1 / Sub-AS 65500 \ |
| | | |
| | Rc . . . . Rd | |
| | . *2 . | |
| \ . . / |
| .-----------------. |
| .*40 .*40 |
| --------------.----- --.----------------- |
| / . \ / . \ |
| | Sub-AS . | | . Sub-AS | |
| | 65501 . | | . 65502 | |
| | Rb | | Re | |
| | . | | . . | |
| | .*10 | | *2. .*3 | |
| | . | | . . | |
| | Ra | | . Rg . . . Rf | |
| \ . / . . / |
| ----------.---------- . -------------.------- |
\ .(0) .(1) .() /
----------------.---------------.-------------------.----------
. . .
--------- . ---------
|AS 200 | |AS 300 |
--------- ---------
. .
. .
-------------------
| AS 400 | - 10.0.0.0/8
-------------------
Figure 3: Example AS Confederations Topology
図3：コンフェデレーショントポロジーとしての例
In Figure 3 AS 1 contains three Sub-ASs, 65500, 65501 and 65502. No RR is used within the Sub-AS, and as such, all routers within each Sub-AS are fully meshed. Ra and Rb are members of Sub-AS 65501. Rc and Rd are members of Sub-AS 65500. Ra and Rg are EBGP peering with AS 200, router Rf has an EBGP peering with AS 300. AS 200 and AS 300 provide transit for AS 400, and in particular, the 10/8 network. The dotted lines are used to represent BGP peering sessions.
図3には、1には3つのサブアス、65500、65501、および65502が含まれています。Sub-AS内でRRは使用されていないため、各サブAS内のすべてのルーターは完全にメッシュ化されています。RAとRBは65501のサブメンバーです。RCとRDはサブAS 65500のメンバーです。RAとRGは200 AS 200のEBGPピアリングです。RouterRFにはAS EBGPが300を覗き込んでいます。400、特に10/8ネットワーク。点線は、BGPピアリングセッションを表すために使用されます。
The number following each '*' on the BGP peering sessions represents the additive IGP metrics that are to be associated with the BGP NEXT_HOP. The number contained in parentheses on each AS 1 EBGP peering session represents the MED value advertised by the peer to be associated with the network reachability advertisement (10.0.0.0/8).
BGPピアリングセッションの各「*」に続く数は、BGP next_hopに関連付けられる追加のIGPメトリックを表します。1つのEBGPピアリングセッションとしてそれぞれの括弧内に含まれる数は、ネットワークの到達可能性広告（10.0.0.0/8）に関連付けられるようにピアによって宣伝されたMED値を表しています。
Rc, Rd and Re are the primary routers involved in the churn, and as such, will be the only BGP tables that we will monitor step by step.
RC、RD、およびREは、チャーンに関与する主要なルーターであり、そのため、段階的に監視する唯一のBGPテーブルになります。
For the following steps 1 through 8 each router's best route will be marked with a '*'.
次の手順1〜8では、各ルーターの最適なルートには「*」でマークされます。
1) Re receives the AS 400 10.0.0.0/8 route advertisement via AS 200 from Rg and AS 300 from Rf. Re selects the path via Rg and AS 200 because of IGP metric (Re didn't consider MED because the advertisements were received from different ASs).
1) REは、RGからAS 200、RFからAS 300を介してAS 400 10.0.0.0/8ルート広告を受け取ります。REは、IGPメトリックのためにRGおよび200としてパスを選択します（REは、広告が異なるお尻から受信されたため、MEDを考慮しませんでした）。
NEXT_HOP
Router AS_PATH MED IGP Cost
------------------------------
Re * 200 400 1 2
300 400 3
Re sends an UPDATE message to Rd advertising its new best path '200 400, 1'.
REはRDに更新メッセージを送信し、新しいベストパス '200 400、1'を宣伝します。
2) The '200 400, 0' path was advertised from Ra to Rb, and then from Rb to Rc. Rd learns the '200 400, 1' path from Re.
2) 「200 400、0」パスはRAからRBに、次にRBからRCに宣伝されました。RDは、Reから「200 400、1」パスを学習します。
NEXT_HOP
Router AS_PATH MED IGP Cost
-------------------------------
Rc * 200 400 0 50
Rd * 200 400 1 42
Re 300 400 3
* 200 400 1 2
3) Rc and Rd advertise their best paths to each other; Rd selects '200 400, 0' because of the MED.
3) RCとRDは、お互いに最適なパスを宣伝しています。RDは、MEDのために「200 400、0」を選択します。
NEXT_HOP
Router AS_PATH MED IGP Cost
------------------------------
Rc * 200 400 0 50
200 400 1 44
Rd * 200 400 0 52
200 400 1 42
Re 300 400 3
* 200 400 1 2
Rd has a new best path so it sends an UPDATE to to Re, announcing the new path and an UPDATE/withdraw for '200 400, 1' to Rc.
RDには新しいベストパスがあるため、更新をREに送信し、新しいパスと「200 400、1」からRCの更新/撤回を発表します。
4) Re now selects '300 400' (with no MED) because '200 400, 0' beats '200 400, 1' based on MED and '300 400' beats '200 400, 0' because of IGP metric.
4) IGPメトリックのために「200 400、0 'beats' 200 400、1 '200 400、1' 200 400、0」に基づいて、「300 400」（MEDなし）を選択します。
NEXT_HOP
Router AS_PATH MED IGP Cost
------------------------------
Rc * 200 400 0 50
Rd * 200 400 0 52
200 400 1 42
Re * 300 400 3
200 400 0 92
Re has a new best path and sends an UPDATE to Rd for '300 400'.
REには新しい最高のパスがあり、「300 400」のRDにアップデートを送信します。
5) Rd selects the '300 400' path because of IGP metric.
5) RDは、IGPメトリックのために「300 400」パスを選択します。
NEXT_HOP
Router AS_PATH MED IGP Cost
------------------------------
Rc * 200 400 0 50
Rd 200 400 0 52
* 300 400 43
Re * 300 400 3
200 400 0 92
200 400 1 2
Rd has a new best path so it sends an UPDATE to Rc and a UPDATE/withdraw to Re for '200 400, 0'.
RDには新しいベストパスがあるため、RCに更新を送信し、「200 400、0」の更新/撤回をREに送信します。
6) Rc selects '300 400' because of the IGP metric. Re selects '200 400, 1' because of the IGP metric.
6) RCは、IGPメトリックのために「300 400」を選択します。IGPメトリックのため、 '200 400、1'を選択します。
NEXT_HOP
Router AS_PATH MED IGP Cost
------------------------------
Rc 200 400 0 50
* 300 400 45
Rd 200 400 0 52
* 300 400 43
Re 300 400 3
* 200 400 1 2
Rc sends an UPDATE/withdraw for '200 400, 0' to Rd. Re sends an UPDATE for '200 400, 1' to Rd.
RCは、「200 400、0」の更新/撤回をRdに送信します。reは「200 400、1」のアップデートをRdに送信します。
7) Rd selects '200 400, 1' as its new best path based on the IGP metric.
7) RDは、IGPメトリックに基づいた新しい最良のパスとして「200 400、1」を選択します。
NEXT_HOP
Router AS_PATH MED IGP Cost
------------------------------
Rc 200 400 0 50
* 300 400 45
Rd * 200 400 1 42
Re 300 400 3
* 200 400 1 2
Rd sends an UPDATE to Rc, announcing '200 400, 1' and implicitly withdraws '300 400'.
RDはRCにアップデートを送信し、「200 400、1」を発表し、暗黙的に「300 400」を撤回します。
8) Rc selects '200 400, 0'.
8) RCは「200 400、0」を選択します。
NEXT_HOP
Router AS_PATH MED IGP Cost
------------------------------
Rc * 200 400 0 50
200 400 1 44
Rd * 200 400 1 42
Re 300 400 3
* 200 400 1 2
At this point we are back to Step 2 and are in a loop.
この時点で、ステップ2に戻り、ループに戻ります。
1) Do not accept MEDs from peers (this may not be a feasible alternative).
1) 仲間からの薬を受け入れないでください（これは実現可能な代替手段ではないかもしれません）。
2) Utilize other BGP attributes higher in the decision process so that the BGP decision algorithm selects a single AS before it reaches the MED step. For example, if local-pref were set based on the advertising AS, then you first eliminate all routes except those in a single AS. In the example, router Re would pick either X or Y based on your local-pref and never change selections.
2) BGP決定アルゴリズムがMEDステップに達する前と同様に、BGP決定アルゴリズムがシングルを選択するように、決定プロセスで他のBGP属性をより高く利用します。たとえば、ASの広告に基づいてLocal-PREFが設定されている場合、最初に単一のルートを除くすべてのルートを排除します。この例では、Router REは、ローカルプレフに基づいてxまたはyのいずれかを選択し、選択を変更することはありません。
This leaves two simple workarounds for the two types of problems.
これにより、2種類の問題に対して2つの単純な回避策が残ります。
Type I: Make inter-cluster or inter-sub-AS link metrics higher than intra-cluster or intra-sub-AS metrics.
タイプI：クラスター間またはsub-inter-sub-asリンクメトリックをクラスター内またはサブ内のメトリックよりも高くします。
Type II: Make route selections based on local-pref assigned to the advertising AS first and then use IGP cost and MED to make selection among routes from the same AS.
タイプII：最初に広告に割り当てられたローカル-PREFに基づいてルート選択を行い、次にIGPコストとMEDを使用して、同じものからルート間で選択します。
Note that this requires per-prefix policies, as well as near intimate knowledge of other networks by the network operator. The authors are not aware of ANY [large] provider today that performs per-prefix policies on routes learned from peers. Implicitly removing this dynamic portion of route selection does not appear to be a viable option in today's networks. The main point is that an available workaround using local-pref so that no two AS's advertise a given prefix at the same local-pref solves type II churn.
これには、Prefixあたりのポリシーが必要であり、ネットワークオペレーターによる他のネットワークのほぼ親密な知識が必要であることに注意してください。著者は、今日、ピアから学んだルートでPrefixあたりのポリシーを実行する[大規模]プロバイダーを認識していません。ルート選択のこの動的部分を暗黙的に削除しても、今日のネットワークでは実行可能なオプションではないようです。主なポイントは、ローカル-PREFを使用して利用可能な回避策を使用して、2つのASが同じローカルPREFで特定のプレフィックスを宣伝しないようにすることです。
3) Always compare BGP MEDs, regardless of whether or not they were obtained from a single AS. This is probably a bad idea since MEDs may be derived in a number of ways, and are typically done so as a matter of operator-specific policy and largely a function of available metric space provided by the employed IGP. As such, comparing MED values for a single prefix learned from multiple ASs is ill-advised. This mostly defeats the purpose of MEDs; Option 1 may be a more viable alternative.
3) BGP MEDを単一から取得したかどうかに関係なく、常に比較してください。MEDはさまざまな方法で導き出される可能性があるため、これはおそらく悪い考えであり、通常、オペレーター固有のポリシーの問題として行われ、主に採用されたIGPによって提供される利用可能なメトリック空間の関数です。そのため、複数のお尻から学習した単一のプレフィックスのMED値を比較することは賢明ではありません。これは主に薬の目的を打ち負かします。オプション1は、より実行可能な代替品かもしれません。
4) Do not use more than one tier of Route Reflection or Sub-ASs in the network. The risk of route oscillation should be considered when designing networks that might use a multi-tiered routing isolation architecture.
4) ネットワークで複数のルートリフレクションやサブアースを使用しないでください。ルート振動のリスクは、マルチ層ルーティング分離アーキテクチャを使用する可能性のあるネットワークを設計する際に考慮する必要があります。
5) In a RR topology, mesh the clients. For confederations, mesh the border routers at each level in the hierarchy. In Figure 3, for example, if Rb and Re are peers, then there's no churn.
5) RRトポロジーでは、クライアントをメッシュします。コンフェデレーションの場合、階層の各レベルで境界線ルーターをメッシュします。たとえば、図3では、RBとREがピアである場合、解約はありません。
It should be stated that protocol enhancements regarding this problem must be pursued. Imposing network design requirements, such as those outlined above, are clearly an unreasonable long-term solution. Problems such as this should not occur under 'default' protocol configurations.
この問題に関するプロトコルの強化を追求する必要があることを述べる必要があります。上記のようなネットワーク設計要件を課すことは、明らかに不合理な長期ソリューションです。このような問題は、「デフォルト」プロトコル構成の下では発生しないでください。
This discussion introduces no new security concerns to BGP or other specifications referenced in this document.
この議論では、このドキュメントで参照されているBGPまたはその他の仕様に新しいセキュリティの懸念は紹介されていません。
The authors would like to thank Curtis Villamizar, Tim Griffin, John Scudder, Ron Da Silva, Jeffrey Haas and Bill Fenner.
著者は、カーティス・ヴィラミザール、ティム・グリフィン、ジョン・スカダー、ロン・ダ・シルバ、ジェフリー・ハース、ビル・フェナーに感謝したいと思います。
[1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[1] Rekhter、Y。およびT. Li、「ボーダーゲートウェイプロトコル4（BGP-4）」、RFC 1771、1995年3月。
[2] Bates, T., Chandra, R. and E. Chen, "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[2] Bates、T.、Chandra、R。、およびE. Chen、「BGPルートリフレクション - フルメッシュIBGPの代替」、RFC 2796、2000年4月。
[3] Traina, P., McPherson, D. and J. Scudder, J., "Autonomous System Confederations for BGP", RFC 3065, February 2001.
[3] Traina、P.、McPherson、D。、およびJ. Scudder、J。、「BGPの自律システムのコンフェデレーション」、RFC 3065、2001年2月。
[4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", Work in Progress.
[4] Rekhter、Y。およびT. Li、「ボーダーゲートウェイプロトコル4（BGP-4）」、進行中の作業。
Danny McPherson TCB EMail: danny@tcb.net
Danny McPherson TCBメール：danny@tcb.net
Vijay Gill AOL Time Warner, Inc. 12100 Sunrise Valley Drive Reston, VA 20191 EMail: vijay@umbc.edu
Vijay Gill Aol Time Warner、Inc。12100 Sunrise Valley Drive Reston、VA 20191 Email：vijay@umbc.edu
Daniel Walton Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 EMail: dwalton@cisco.com
Daniel Walton Cisco Systems、Inc。7025 Kit Creek Rd。研究トライアングルパーク、NC 27709メール：dwalton@cisco.com
Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 EMail: aretana@cisco.com
Alvaro Retana Cisco Systems、Inc。7025 Kit Creek Rd。研究トライアングルパーク、NC 27709メール：aretana@cisco.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。