この文書はRFC3345の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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
ボーダーゲートウェイプロトコル（ＢＧＰ）の持続的経路振動条件
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.
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.
特定の設定で、「ＢＧＰ経路反射－完全メッシュＩＢＧＰの代替」と「ＢＧ
Ｐ自律システム同盟」で定義されるＢＧＰスケールメカニズムは持続的なＢ
ＧＰ経路の振動をもたらします。この文書は確認された継続的経路振動の２
つのタイプを論じて、これらの状態が存在する場合を記述し、そしてこのよ
うな事象が発生するのを避けるためのあるネットワークデザインガイドライ
ンを供給します。
1. Introduction
1. はじめに
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.
ボーダーゲートウェイプロトコル（ＢＧＰ）は自律システム間のルーティン
グプロトコルです。ＢＧＰ装置の主機能は、他のＢＧＰシステムと、ネット
ワーク可到達性情報をを交換することです。
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.
特定の設定で、「ＢＧＰ経路反射－完全メッシュＩＢＧＰの代替」[2]と「Ｂ
ＧＰ自律システム同盟」[3]で定義されたＢＧＰ[1]スケーラブルメカニズム
はＢＧＰ経路振動を生じます。
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.
問題はＢＧＰの動作方法に固有です：ローカルに定義されたルーティングポ
リシーがグローバルと矛盾するかもしれません、そしてある特定の種類の矛
盾が継続的振動を起こすことがあります。現在の習慣下で、我々はたまたま
ＭＥＤ＋経路反射あるいは同盟という環境で問題が明らかになるのを見まし
た。
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]
ＢＧＰ－４[4]の現在の仕様は、同じ近隣ＡＳから学んだ経路間でのみ
MULTI_EXIT_DISCが比較できるだけであると述べます。この限界は属性の記
述と整合しています：「MULTI_EXIT_DISC属性は、同じ近隣ＡＳへの多数の
出口あるいは入り口を区別するために、外部（ＡＳ間）リンクで使われるか
もしれません」[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.
完全メッシュｉＢＧＰネットワークで、すべての内部ルータは隣接ＡＳの利
用可能な出口が完全に見えています。同じパスだけの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.
フルのメッシュｉＢＧＰネットワークのスケーラビリティの意味のために、
２つの選択肢が標準化されていました：経路反射[2]とＡＳ同盟[3]。両方の
選択肢でＡＳで完全ｉＢＧＰメッシュなしで経路配布が成し遂げられるかも
しれない方法を記述します。
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.
経路反射選択肢は、最良パスが選ばれたら、ｉＢＧＰによって学ばれた経路
を他のｉＢＧＰピアに再度広告する（反射）能力[2]を定義します。ＡＳ同盟
は共通の管理者下の自律システム集合を、ひとつの要素として、運用する事
を示します（すなわち、外部から、内部のトポロジーと別の自律システムの
存在は見えない）。両方の場合に、ｉＢＧＰ完全メッシュの縮小はＡＳのす
べてのＢＧＰスピーカが隣接するＡＳの利用可能な出口ポイントに対する完
全な視界を持っているわけではないという事実をもたらします。実際、ＡＳ
内でのルータの場所（と機能）によって、視界は部分的で一貫してないかも
しれません。
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.
継続的経路振動動作は決定的動作であり、プロトコル拡張が問題を解決する
まで、ある基本的ＢＧＰネットワークデザインの原則を使用することによっ
て避ることができます。
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.
変動は下記に記述した基準でタイプⅠとタイプⅡに分類されます。
2. Discussion of Type I Churn
2. タイプⅠ振動の論議
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.
次の２つの章で、我々はタイプⅠ振動を引き起こす設定を供給します。我々
は、経路反映を使う時の問題の論議から始め、そして次にＡＳ同盟に関連し
ている問題を論じます。
In general, Type I Churn occurs only when BOTH of the following
conditions are met:
一般に、タイプⅠ振動は以下の両方の状況が発生した時だけ起こります：
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) ネットワークが１つのプレフィックスに対してＢＧＰの
MULTI_EXIT_DISC(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]はパスがＥＭＤ順に並べるべきだと指定しませんが、順番が決まっていな
いとループと一貫しない経路を導くことがあることは証明されています。た
いていのベンダが決まった順序をデフォルト動作として導入するか、あるい
はオペレータがルータをＭＥＤに基づいた順序にするように設定するのを許
す方法を供給しています。
2.1. Route Reflection and Type I Churn
2.1. 経路反射とタイプⅠ振動
We now discuss Type I oscillation as it relates to Route Reflection.
To begin, consider the topology depicted in Figure 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
図１：経路反射トポロジー例
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.
図１でＡＳ１が２つの経路反射クラスタ、クラスタ１とクラスタ２を含んで
います。各クラスタが１つの経路反射（ＲＲ）（すなわち、それぞれＲａと
Ｒｄ）を含んでいます。括弧付けの「ＲＲ」は各ＲＲを表現します。クラス
タ１には２つのＲＲクライアント（ＲｂとＲｃ）を含み、クラスタ２には１
つのＲＲクライアント（Ｒｅ）を含みます。括弧付けの「Ｃ」がＲＲクライ
アント状態を示します。点線はＢＧＰピアリングセッションを表すために使
われます。
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.
ＡＳ１のＥＢＧＰピアリングセッションの括弧内の数字は１０.０.０.０／８
ネットワーク到達可能性広告でピアが広告した、ＭＥＤ値です。
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.
ＩＢＧＰピアリングセッションにそれぞれの「＊」の後に続いている数は、
問題の経路のＢＧＰのNEXT_HOP属性と結び付けられるはずである追加のＩＧ
Ｐ距離を表します。例えば、Ｒｂから学んだNEXT_HOPと結び付けられたＲａ
のＩＧＰ距離は５です；Ｒａから学んだNEXT_HOPと結び付けられた距離が
１３です。
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.
表１は、それぞれルータＲｂとＲｃとＲｅで見られる、１０.０.０.０／８経
路の属性を示します。図１でのＩＧＰ距離が、ＩＢＧＰピアに経路を広告す
る時だけの、問題であることに注意してください。
Router MED AS_PATH
--------------------
Rb 10 10 100
Rc 1 6 100
Re 0 6 100
Table 1: Route Attribute Table
表１：経路属性表
For the following steps 1 through 5, the best path will be marked
with a '*'.
次の１から５までのステップで、最も良いパスは「＊」マークが付くでしょう。
1) Ra has the following installed in its BGP table, with the path
learned via AS2 marked best:
1) Ｒａは以下のＢＧＰテーブルがあり、ＡＳ２から学んだパスが最良と
印されています：
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」経路は、これが継続的経路振動の原因ではないけれども、
最良と印されるべきではありません。Ｒａは「6 100」パスがより低い
ＩＧＰメトリックを持つので、間違った経路に最良というマークを付
けられたことを悟ります。そして、Ｒａは変更し、「6 100, 1, 4」経
路が最良である事を知らせるため、更新メッセージを近隣へ広告します。
2) Rd receives the UPDATE from Ra, which leaves Rd with the
following installed in its BGP table:
2) ＲｄがＲａから更新を受け取り、Ｒｄが次の通りのＢＧＰテーブルを
持ちます：
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.
Ｒｄは「6 100, 0, 12」経路が低いＭＥＤを持つので最良経路と印し
をつけます。Ｒｄはこれが最良経路である事を知らせるために近隣に
更新メッセージを送ります。
3) Ra receives the UPDATE message from Rd and now has the
following in its BGP table:
3) ＲａはＲｄから更新メッセージを受取り、そして以下のＢＧＰテーブ
ルを持ちます：
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）はより低いＭＥＤのために２番目の経路
（6 100, 1, 4）より良いです。それから３番目の経路（10 100, 10,
5）はNEXT_HOPにより低いＩＧＰ距離があるので最初の経路より良い
です。Ｒａは新しい最良経路を知らせるためピアに更新メッセージを
送ります。
4) Rd receives the UPDATE message from Ra, which leaves Rd with
the following BGP table:
4) ＲｄがＲａから更新メッセージを受取り、Ｒｄは以下のＢＧＰテーブ
ルを持ちます：
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.
Ｒｄが「10 100, 10, 6」パスをＩＧＰ距離により最良として選びます。
Ｒｄがピアにこれが最良経路である事を知らせる更新／撤回を送ります。
5) Ra receives the UPDATE message from Rd, which leaves Ra with
the following BGP table:
5) ＲａはＲｄから更新メッセージを受取り、Ｒａは以下のＢＧＰテーブ
ルを持ちます：
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.
Ｒａは、Ｒａが最良経路と思っている経路を変える、「6 100, 0, 13」
の更新／撤回を受けます。これは「6 100, 1, 4」が実際いは良いにも
かかわらず、Ｒａがステップ１で「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.
この時点で、完全なループができ、そしてステップ１に戻っています。ルー
タは正しくない最良パスを使っていることを悟り、そしてサイクルを繰り
返します。これは経路反射を使う場合のタイプⅠ振動の例です。
2.2. AS Confederations and Type I Churn
2.2. ＡＳ同盟とタイプⅠ振動
Now we provide an example of Type I Churn occurring with AS
Confederations. To begin, consider the topology depicted in Figure
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
図２：例ＡＳ同盟トポロジー
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.
各ＡＳ１のＥＢＧＰピアリングセッションの括弧内の数字は、ピアから広告
された１０.０.０.０／８ネットワーク到達可能性広告と結び付けられＭＥＤ
値です。
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.
ＩＢＧＰピアリングセッションにそれぞれの「*」の後に続いている数は、問
題の経路のＢＧＰ NEXT_HOP属性に関連する追加のＩＧＰ距離を表します。
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.
例えば、Ｒｂから学んだNEXT_HOPと結び付けられたＲａ ＩＧＰ距離値が３で
す；Ｒｅから学んだNEXT_HOPと結び付けられた距離値は６です。
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.
表２が、それぞれルータＲｂとＲｃとＲｅから見れる１０.０.０.０／８経路
の属性をを描写します。図２のＩＧＰ距離が、ＩＢＧＰピアに経路を広告す
る時だけの問題であることに注意してください。
Router MED AS_PATH
--------------------
Rb 10 10 100
Rc 1 6 100
Re 0 6 100
Table 2: Route Attribute Table
表２：経路属性表
For the following steps 1 through 6 the best route will be marked
with an '*'.
次の１から６までのステップの最良経路は「*」で印します。
1) Ra has the following BGP table:
1) Ｒａは次のＢＧＰテーブルを持っています：
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」経路は最良として選ばれて、これが継続的経路振動の原因
ではないけれども、Ｒｄに広告されます。
2) Rd has the following in its BGP table:
2) Ｒｄが以下のＢＧＰテーブルを持ちます：
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」経路が、最低のＩＧＰ距離を持つので、最良とし
て選ばれます。結果として、ＲｄがＲａに前に広告した「6 100」経路
の更新／撤回を送信します。
3) Ra receives the withdraw from Rd. Ra now has the following in
its BGP table:
3) ＲａがＲｄからの撤回を受信します。Ｒａは以下のＢＧＰテーブルで
今持っています：
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.
Ｒａは「(65001) 6 100」の撤回を受取り、これはＲａが最良と思う経
路を変更します。Ｒａは、最良経路経路が撤回されなかったなら、プ
レフィックスの最良パスを計算しません。これは「10 100, 10, 3」経
路が良くても、Ｒａが「6 100, 1, 2」経路を最良と選択した理由です。
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) Ｒａの周期的ＢＧＰ調査が動き、そして「6 100」経路がＩＧＰ距離が
小さいのでより良いことを悟ります。Ｒａは「6 100」パスが最良とし
て使用するので、「10 100」経路の更新／撤回をＲｄへ送ります。
Ra's BGP table looks like this:
ＲａのＢＧＰテーブルは以下の通りです：
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) ＲｄがＲａから更新を受け取り、そしてＢＧＰテーブルは以下の通り
です：。
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.
Ｒｄが「6 100, 0, 6」経路をＭＥＤ値が最も小さいので、最良と選び
ます。ＲｄがＲａに更新メッセージを送り、「6 100, 0, 6」が今最も
良い経路であると報告します。
6) Ra receives the UPDATE from Rd. Ra now has the following in
its BGP table:
6) ＲａはＲｄから更新を受け取ります。ＲａのＢＧＰテーブルは以下の
通りです：
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.
この時点で我々は完全なサイクルを作り、そしてステップ１に戻って
います。これはＡＳ同盟によるタイプⅠ振動の例です。
2.3. Potential Workarounds for Type I Churn
2.3. タイプⅠ振動の可能性がある回避策
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) 経路反射を使う時、クラスタ間リンクがクラスタ内リンクより高いＩ
ＧＰ距離を持つ事を確実にします。これは、経路反射を使う時、望ま
しい選択です。もしクラスタ間ＩＧＰ距離ががクラスタ内ＩＧＰ距離
より大きかったなら、上記の事が起こらないでしょう。
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) ＡＳ同盟を使う時、サブＡＳ間リンクがサブＡＳ内リンクより高いＩ
ＧＰ距離を持つ事を確実にします。これは、ＡＳ同盟を使う時、望ま
しい選択です。もしサブＡＳ間ＩＧＰ距離ががサブＡＳ内ＩＧＰ距離
より大きかったなら、上記の事が起こらなかったでしょう。
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) ＢＧＰ決定アルゴリズムが決してＭＥＤステップに達しないように、
決定プロセスでより優先順位の高いＢＧＰ属性を利用します。これが
完全にＭＥＤより優先するように、３案が有用かもしれません。
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) 同じＡＳから得たかにかかわらず、常にＢＧＰのＭＥＤを比較します。
これは、 ＭＥＤの決定方法は様々で、一般にオペレータ固有のポリシ
で決定されるので、恐らく良くない考えです。それで、多数のＡＳか
ら学んだ同じプレフィックスでＭＥＤ値を比較することは無意味です。
もちろん、これはほとんどのＭＥＤの目的に合致せず、そして３案が
より実行可能な代案かもしれません。
6) Use a full IBGP mesh. This is not a feasible solution for ASs
with a large number of BGP speakers.
6) 完全ＩＢＧＰメッシュを使う。これは多数のＢＧＰスピーカの存在す
るＡＳで実行可能な解決策ではありません。
3. Discussion of Type II Churn
3. タイプⅡ振動の論議
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.
次の章で我々はＡＳ同盟を使用する際に生じるタイプⅡ振動を発生する設定
を示します。簡単にするために、経路反射を使う時に生じる類似の論議を避
けます。
In general, Type II churn occurs only when BOTH of the following
conditions are met:
一般に、タイプⅡ振動が、次の状態の両方が存在する時だけ、起こります：
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) ネットワークはひとつのプレフィックスで２つ以上のＡＳからＢＧＰ
多数出口（ＭＥＤ）属性を受け入れ、そしてＭＥＤ値はユニークです。
3.1. AS Confederations and Type II Churn
3.1. ＡＳ同盟とタイプⅡ振動
Let's now examine the occurrence of Type II Churn as it relates to AS
Confederations. Figure 3 provides our sample topology:
ＡＳ同盟に関連している、タイプⅡ振動の発生を調べましょう。図３が我々
のトポロジー例を供給します：
---------------------------------------------------------------
/ ------------------- \
| 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
図３：ＡＳ同盟トポロジー例
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.
図３で、ＡＳ１が３つの副ＡＳ、６５５００と６５５０１と６５５０２を含
んでいます。副ＡＳでは経路反射は使われず、そして各副ＡＳのルータは完
全メッシュです。ＲａとＲｂは副ＡＳ６５５０１のメンバです。ＲｃとＲｄ
は副ＡＳ６５５００のメンバです。ＲａとＲｇはＡＳ２００とＥＢＧＰピア
リングをし、ルータＲｆはＡＳ３００でＥＢＧＰピアリングをしています。
ＡＳ２００とＡＳ３００がＡＳ４００の、特に10/8ネットワークの、中継を
供給ます。点線はＢＧＰピアリングセッションを表すために使われます。
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).
ＢＧＰピアリングセッションにそれぞれの「*」の後に続いている数はＢＧＰ
のNEXT_HOPと結び付けられる追加のＩＧＰ距離を表します。各ＡＳ１のＥＢ
ＧＰピアリングセッションの括弧内の数は、ピアから広告されたネットワー
ク到達可能性広告（１０.０.０.０／８）と結び付いたＭＥＤ値です。
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.
ＲｃとＲｄとＲａは振動に関係している主要なルータであり、そして我々が
一歩一歩モニタするＢＧＰテーブルです。
For the following steps 1 through 8 each router's best route will be
marked with a '*'.
次の１から８までのステップのためにそれぞれのルータの最も良いルートは
”*”で印されます。
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) ＲｅがＡＳ４００の１０.０.０.０／８経路を、ＲｇからＡＳ２００
経由として、ＲｆからＡＳ３００経由として受取ります。ＲｅがＩＧ
ＰメトリックによりＲｇとＡＳ２００の経路を選びます（異なるＡＳ
からの広告なので、ＲｅはＭＥＤを考慮しません）。
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'.
ＲｅがＲｄに新しい最もよい経路「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」経路はＲａからＲｂと、そして次にＲｂからＲｃに広
告されました。ＲｄがＲｅから「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) ＲｃとＲｄはお互いに最も良い経路を広告します；ＲｄがＭＥＤによ
り「'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.
Ｒｄが新しい最良経路を持っているので、新しい経路を広告する更新
をＲｅに送り、Ｒｃに「200 400, 1」の更新／撤回を送ります。
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) Ｒｅは今「300 400」（ＭＥＤがなし）を選択します、というのは、
ＭＥＤにより「200 400, 0」が「200 400, 1」よりよく、ＩＧＰメト
リックにより「300 400」が「200 400, 0」よりよいからです。
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'.
Ｒｅが新しい最も良い経路を持ち、そしてＲｄに経路「300 400」の更
新を送ります。
5) Rd selects the '300 400' path because of IGP metric.
5) ＲｄがＩＧＰ距距離により「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'.
Ｒｄが新しい最も良い経路を持っています、それでＲｃに更新を送り、
Ｒｅに「200 400, 0」の更新／撤回を送ります。
6) Rc selects '300 400' because of the IGP metric. Re selects
'200 400, 1' because of the IGP metric.
6) ＲｃはＩＧＰ距離のために「300 400」を選択します。ＲｅがＩＧＰ距
離のために「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.
ＲｃはＲｄに「200 400, 0」の更新／撤回を送ります。ＲｅがＲｄに
「200 400, 1」に更新を送ります。
7) Rd selects '200 400, 1' as its new best path based on the IGP
metric.
7) ＲｄがＩＧＰ距離に基づいて最良経路として「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'.
ＲｄがＲｃに更新を送り、「200 400, 1」を広告し、そして暗黙に
「300 400」を撤回します。
8) Rc selects '200 400, 0'.
8) Ｒｃは「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.
この時点で我々はステップ２に戻り、そしてループができています。
3.2. Potential Workarounds for Type II Churn
3.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) ＢＧＰ決定アルゴリズムが、ＭＥＤステップに達する前に、１つのＡＳを
選択するように、決定プロセスでより高くい優先順位の他のＢＧＰ属性を
利用する。例えば、もしローカル優先広告されたＡＳで設定されたら、あ
るＡＳで最初に他のすべての経路を排除します。例で、ルータＲｅがロー
カル優先に基づいてＸかＹを選択し、選択を変えないでしょう。
This leaves two simple workarounds for the two types of problems.
これは２つのタイプの問題のために２つの単純な回避策を残しておきます。
Type I: Make inter-cluster or inter-sub-AS link metrics higher
than intra-cluster or intra-sub-AS metrics.
タイプⅠ：クラスタ間あるいは副ＡＳ間リンクの距離を、クラスタ内ある
いは副ＡＳ間距離より高くします。
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.
タイプⅡ：最初に広告業ＡＳに割り当てられたローカル優先に基づいて経
路選択をして、そして次に同じＡＳからの経路の間の選択をするためにＩ
ＧＰコストとＭＥＤを使います。
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.
これが、プレフィックス毎のポリシーを必要とし、ネットワークオペレー
タが他のネットワークの詳細な知識を知っている必要があることに注意し
てください。著者は今日ピアから学んだ経路でプレフィックス毎にポリシー
を行う［大きい］プロバイダを知りません。暗黙に、経路選択のこのダイ
ナミックな部分を取り去ることは、今日のネットワークで実行可能な選択
であるように思われません。主な要点は、あるプレフィックスで同じロー
カル優先の広告を複数のＡＳが広告しないで、ローカル優先を使う利用可
能な回避策がタイプⅡ振動を解決するということです。
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) それらが同じＡＳから得られたかどうかにかかわらず、常にＢＧＰのＭＥ
Ｄを比較します。これはＭＥＤが多くの方法で得られるかもしれず、そし
て典型的にオペレータ固有のポリシーに依存し、ＩＧＰから供給された利
用可能な距離空間の関数なので、恐らく良くない考えです。それで、ある
プレフィックスについて、多数のＡＳから学んだＭＥＤ値を比較すること
は無分別です。これはたいていＭＥＤの目的を壊します；オプション１は
より実行可能な代案であるかもしれません。
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) ＲＲトポロジーで、クライアントをメッシュにする。同盟で、階層のそれ
ぞれのレベルで、境界ルータをメッシュにする。図３で、例えば、もしＲ
ｂとＲｅがピアであるなら、振動がありません。
4. Future Work
4. 今後の仕事
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.
この問題に関係しているプロトコル拡張が追求されなくてはならないと明記
します。上に概要を描いたような、変なネットワークデザイン条件は明らか
に不当な長期解決策です。このような問題が「デフォルト」プロトコル設定
下で起こるべきではありません。
5. Security Considerations
5. セキュリティの考察
This discussion introduces no new security concerns to BGP or other
specifications referenced in this document.
この論議はＢＧＰあるいはこの文書で参照された他の仕様書に新しいセキュ
リティの懸念を導入しません。
6. Acknowledgments
6. 謝辞
The authors would like to thank Curtis Villamizar, Tim Griffin, John
Scudder, Ron Da Silva, Jeffrey Haas and Bill Fenner.
著者はCurtis VillamizarとTim GriffinとJohn ScudderとRon Da Silvaと
Jeffrey HaasとBill Fennerに感謝したいです。
7. References
７．参考文献
[1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC
1771, March 1995.
[2] Bates, T., Chandra, R. and E. Chen, "BGP Route Reflection - An
Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[3] Traina, P., McPherson, D. and J. Scudder, J., "Autonomous System
Confederations for BGP", RFC 3065, February 2001.
[4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
Work in Progress.
8. Authors' Addresses
8. 著者のアドレス
Danny McPherson
TCB
EMail: danny@tcb.net
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
Alvaro Retana
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
EMail: aretana@cisco.com
9. Full Copyright Statement
9. 著作権表示全文
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（Ｃ）インターネット学会（２００３）。すべての権利は保留される。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。