RFC2796 日本語訳
2796 BGP Route Reflection - An Alternative to Full Mesh IBGP. T.Bates, R. Chandra, E. Chen. April 2000. (Format: TXT=20174 bytes) (Obsoleted by RFC4456) (Updates RFC1966) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Bates
Request for Comments: 2796 Cisco Systems
Updates: 1966 R. Chandra
Category: Standards Track E. Chen
Redback Networks
April 2000
ネットワークワーキンググループT.はコメントを求める要求を和らげます: 2796のシスコシステムズアップデート: 1966年のR.チャンドラカテゴリ: 規格は2000年4月にE.チェン20ドル紙幣ネットワークを追跡します。
BGP Route Reflection -
An Alternative to Full Mesh IBGP
BGPルート反射--完全なメッシュIBGPへの代替手段
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3].
ボーダ・ゲイトウェイ・プロトコル[1]はTCP/IPインターネットのために設計された相互自律システムルーティング・プロトコルです。 現在インターネットBGP展開では、構成されたそのようなものが完全に網の目にかけられるので、そのASの中の他のすべてのルータにどんな外部のルーティング情報も再配付しなければなりません。 これはいくつかの選択肢が提案されている状態でよく記録された重大なスケーリング問題[2、3]を表します。
This document describes the use and design of a method known as "Route Reflection" to alleviate the the need for "full mesh" IBGP.
このドキュメントは、「完全なメッシュ」IBGPの必要性を軽減するために「ルート反射」として知られている方法の使用とデザインについて説明します。
1. Introduction
1. 序論
Currently in the Internet, BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed and any external routing information must be re-distributed to all other routers within that AS. For n BGP speakers within an AS that requires to maintain n*(n-1)/2 unique IBGP sessions. This "full mesh" requirement clearly does not scale when there are a large number of IBGP speakers each exchanging a large volume of routing information, as is common in many of todays internet networks.
現在、インターネットでは、BGP展開は構成されて、独身のASの中のすべてのBGPスピーカーを完全に網の目にかけなければならないくらいのそれとどんな外部のルーティング情報もそのASの中の他のすべてのルータに再配付しなければならないということです。 それがn*(n-1)/2つのユニークなIBGPセッションを維持するのを必要とするASの中のn BGPスピーカーのために。 それぞれ今日のインターネットネットワークの多くで一般的にそのままな多くのルーティング情報を交換する多くのIBGPスピーカーがいるとき、この「完全なメッシュ」要件は明確に比例しません。
Bates, et al. Standards Track [Page 1] RFC 2796 BGP Route Reflection April 2000
ベイツ、他 規格はBGPルート反射2000年4月にRFC2796を追跡します[1ページ]。
This scaling problem has been well documented and a number of proposals have been made to alleviate this [2,3]. This document represents another alternative in alleviating the need for a "full mesh" and is known as "Route Reflection". This approach allows a BGP speaker (known as "Route Reflector") to advertise IBGP learned routes to certain IBGP peers. It represents a change in the commonly understood concept of IBGP, and the addition of two new optional transitive BGP attributes to prevent loops in routing updates.
このスケーリング問題をよく記録しました、そして、これ[2、3]を軽減するのを多くの提案をしました。 このドキュメントは、「完全なメッシュ」の必要性を軽減する際に別の代替手段を表して、「ルート反射」として知られています。 このアプローチで、BGPスピーカー(「ルート反射鏡」として、知られている)は確信しているIBGP同輩にIBGPの学術的ルートの広告を出すことができます。 それはIBGPの一般的に理解されている概念における変化を表します、そして、防ぐ2つの新しい任意の他動なBGP属性の添加はルーティングアップデートで輪にされます。
This document is a revision of RFC1966 [4], and it includes editorial changes, clarifications and corrections based on the deployment experience with route reflection. These revisions are summarized in the Appendix.
このドキュメントはRFC1966[4]の改正です、そして、それはルート反射の展開経験に基づく編集の変化、明確化、および修正を含んでいます。 これらの改正はAppendixにまとめられます。
2. Design Criteria
2. 設計基準
Route Reflection was designed to satisfy the following criteria.
ルートReflectionは、以下の評価基準を満たすように設計されました。
o Simplicity
o 簡単さ
Any alternative must be both simple to configure as well as
understand.
どんな選択肢も構成して、理解しているのはともに簡単でなければなりません。
o Easy Transition
o 簡単な変遷
It must be possible to transition from a full mesh
configuration without the need to change either topology or AS.
This is an unfortunate management overhead of the technique
proposed in [3].
それはトポロジーかASのどちらかを変える必要性なしで完全なメッシュ網からの変遷に可能であるに違いありません。 これは[3]で提案されたテクニックの不幸な管理オーバーヘッドです。
o Compatibility
o 互換性
It must be possible for non compliant IBGP peers to continue be
part of the original AS or domain without any loss of BGP
routing information.
非対応することのIBGP同輩が続くのは、BGPの少しも損失のないオリジナルのASかドメインの一部がルーティング情報であったなら可能であるに違いありません。
These criteria were motivated by operational experiences of a very large and topology rich network with many external connections.
これらの評価基準は多くの外部の接続による非常に大きい、そして、トポロジーの豊かなネットワークの運用経験で動機づけられました。
3. Route Reflection
3. ルート反射
The basic idea of Route Reflection is very simple. Let us consider the simple example depicted in Figure 1 below.
Route Reflectionの基本的な考え方は非常に簡単です。 以下の図1に表現された簡単な例を考えましょう。
Bates, et al. Standards Track [Page 2] RFC 2796 BGP Route Reflection April 2000
ベイツ、他 規格はBGPルート反射2000年4月にRFC2796を追跡します[2ページ]。
+-------+ +-------+
| | IBGP | |
| RTR-A |--------| RTR-B |
| | | |
+-------+ +-------+
\ /
IBGP \ ASX / IBGP
\ /
+-------+
| |
| RTR-C |
| |
+-------+
+-------+ +-------+ | | IBGP| | | RTR-A|--------| RTR-B| | | | | +-------+ +-------+ \/IBGP\ASX / IBGP\/+-------+ | | | RTR-C| | | +-------+
Figure 1: Full Mesh IBGP
図1: 完全なメッシュIBGP
In ASX there are three IBGP speakers (routers RTR-A, RTR-B and RTR- C). With the existing BGP model, if RTR-A receives an external route and it is selected as the best path it must advertise the external route to both RTR-B and RTR-C. RTR-B and RTR-C (as IBGP speakers) will not re-advertise these IBGP learned routes to other IBGP speakers.
ASXに、3人のIBGPスピーカー(ルータのRTR-A、RTR-B、およびRTR C)がいます。 RTR-Aが外部経路を受けて、最も良い経路として選定されるなら、既存のBGPモデルと共に、それはRTR-BとRTR-Cの両方に外部経路の広告を出さなければなりません。 RTR-BとRTR-C(IBGPスピーカーとしての)はこれらのIBGPの学術的ルートの他のIBGPスピーカーに再広告を出さないでしょう。
If this rule is relaxed and RTR-C is allowed to advertise IBGP learned routes to IBGP peers, then it could re-advertise (or reflect) the IBGP routes learned from RTR-A to RTR-B and vice versa. This would eliminate the need for the IBGP session between RTR-A and RTR-B as shown in Figure 2 below.
この規則がリラックスして、RTR-CがIBGPの学術的ルートのIBGP同輩に広告を出すことができるなら、それはRTR-AからRTR-Bまで逆もまた同様に学習されたIBGPルートの再広告を出すかもしれません(反射してください)。 これは以下の図2に示されるようにRTR-AとRTR-BとのIBGPセッションの必要性を排除するでしょう。
+-------+ +-------+
| | | |
| RTR-A | | RTR-B |
| | | |
+-------+ +-------+
\ /
IBGP \ ASX / IBGP
\ /
+-------+
| |
| RTR-C |
| |
+-------+
+-------+ +-------+ | | | | | RTR-A| | RTR-B| | | | | +-------+ +-------+ \/IBGP\ASX / IBGP\/+-------+ | | | RTR-C| | | +-------+
Figure 2: Route Reflection IBGP
図2: ルート反射IBGP
The Route Reflection scheme is based upon this basic principle.
Route Reflection計画はこの基本原理に基づいています。
Bates, et al. Standards Track [Page 3] RFC 2796 BGP Route Reflection April 2000
ベイツ、他 規格はBGPルート反射2000年4月にRFC2796を追跡します[3ページ]。
4. Terminology and Concepts
4. 用語と概念
We use the term "Route Reflection" to describe the operation of a BGP speaker advertising an IBGP learned route to another IBGP peer. Such a BGP speaker is said to be a "Route Reflector" (RR), and such a route is said to be a reflected route.
私たちは、別のIBGP同輩にIBGPの学術的ルートの広告を出すBGPスピーカーの操作について説明するのに「ルート反射」という用語を使用します。 そのようなBGPスピーカーは「ルート反射鏡」(RR)であると言われています、そして、そのようなルートは反射したルートであると言われています。
The internal peers of a RR are divided into two groups:
RRの内部の同輩は2つのグループに分割されます:
1) Client Peers
1) クライアント同輩
2) Non-Client Peers
2) 非クライアント同輩
A RR reflects routes between these groups, and may reflect routes among client peers. A RR along with its client peers form a Cluster. The Non-Client peer must be fully meshed but the Client peers need not be fully meshed. Figure 3 depicts a simple example outlining the basic RR components using the terminology noted above.
RRはこれらのグループの間のルートを反映して、クライアント同輩の中でルートを反映するかもしれません。 クライアント同輩に伴うRRはClusterを形成します。 Non-クライアント同輩を完全に網の目にかけなければなりませんが、Client同輩は完全に網の目にかけられなければならないというわけではありません。 図3は上に述べられた用語を使用することで基本的なRRの部品について概説する簡単な例について表現します。
/ - - - - - - - - - - - - - -
| Cluster |
+-------+ +-------+
| | | | | |
| RTR-A | | RTR-B |
| |Client | |Client | |
+-------+ +-------+
| \ / |
IBGP \ / IBGP
| \ / |
+-------+
| | | |
| RTR-C |
| | RR | |
+-------+
| / \ |
- - - - - /- - -\- - - - - - /
IBGP / \ IBGP
+-------+ +-------+
| RTR-D | IBGP | RTR-E |
| Non- |---------| Non- |
|Client | |Client |
+-------+ +-------+
/ - - - - - - - - - - - - - - | クラスタ| +-------+ +-------+ | | | | | | | RTR-A| | RTR-B| | |クライアント| |クライアント| | +-------+ +-------+ | \ / | IBGP\/IBGP| \ / | +-------+ | | | | | RTR-C| | | RR| | +-------+ | / \ | - - - - - /、-、--、-、\、-、--、--、--、--、--、/ IBGP /\IBGP+-------+ +-------+ | RTR-D| IBGP| RTR-E| | 非|---------| 非| |クライアント| |クライアント| +-------+ +-------+
Figure 3: RR Components
図3: RRの部品
Bates, et al. Standards Track [Page 4] RFC 2796 BGP Route Reflection April 2000
ベイツ、他 規格はBGPルート反射2000年4月にRFC2796を追跡します[4ページ]。
5. Operation
5. 操作
When a RR receives a route from an IBGP peer, it selects the best path based on its path selection rule. After the best path is selected, it must do the following depending on the type of the peer it is receiving the best path from:
RRがIBGP同輩からルートを受けるとき、それは経路選択規則に基づく中で最も良い経路を選択します。 最も良い経路が選択された後に、受けている中で経路最も良い同輩のタイプで以下の依存をしなければなりません:
1) A Route from a Non-Client IBGP peer
1) Non-クライアントIBGP同輩からのRoute
Reflect to all the Clients.
すべてのClientsに反射してください。
2) A Route from a Client peer
2) Client同輩からのRoute
Reflect to all the Non-Client peers and also to the Client
peers. (Hence the Client peers are not required to be fully
meshed.)
すべてのNon-クライアント同輩と、そして、Client同輩にも反射してください。 (したがって、Client同輩は完全に網の目にかけられる必要はありません。)
An Autonomous System could have many RRs. A RR treats other RRs just like any other internal BGP speakers. A RR could be configured to have other RRs in a Client group or Non-client group.
Autonomous Systemは多くのRRsを持つことができました。 RRはまさしくいかなる他の内部のBGPスピーカーのような他のRRsも扱います。 ClientグループかNon-クライアントグループで他のRRsを持つためにRRを構成できました。
In a simple configuration the backbone could be divided into many clusters. Each RR would be configured with other RRs as Non-Client peers (thus all the RRs will be fully meshed.). The Clients will be configured to maintain IBGP session only with the RR in their cluster. Due to route reflection, all the IBGP speakers will receive reflected routing information.
簡単な構成では、背骨を多くのクラスタに分割できました。 各RRはNon-クライアント同輩として他のRRsによって構成されるでしょう(その結果、すべてのRRsが完全に網の目にかけられるでしょう。)。 Clientsは、彼らのクラスタでRRだけとのIBGPセッションを維持するために構成されるでしょう。 ルート反射のため、スピーカーが受け取るすべてのIBGPがルーティング情報を反映しました。
It is possible in a Autonomous System to have BGP speakers that do not understand the concept of Route-Reflectors (let us call them conventional BGP speakers). The Route-Reflector Scheme allows such conventional BGP speakers to co-exist. Conventional BGP speakers could be either members of a Non-Client group or a Client group. This allows for an easy and gradual migration from the current IBGP model to the Route Reflection model. One could start creating clusters by configuring a single router as the designated RR and configuring other RRs and their clients as normal IBGP peers. Additional clusters can be created gradually.
Autonomous Systemでは、Route-反射鏡の概念を理解していないBGPスピーカーがいるのは、可能です(それらを従来のBGPスピーカーと呼びましょう)。 Route-反射鏡Schemeはそのような従来のBGPスピーカーを共存させます。 従来のBGPスピーカーは、Non-クライアントグループのメンバーかClientグループのどちらかであるかもしれません。 これは簡単でゆるやかな現在のIBGPモデルからRoute Reflectionモデルまでの移動を考慮します。 1つは、指定されたRRとしてただ一つのルータを構成して、正常なIBGPがじっと見るので他のRRsと彼らのクライアントを構成することによってクラスタを作成し始めるかもしれません。 徐々に追加クラスタを作成できます。
6. Redundant RRs
6. 余分なRRs
Usually a cluster of clients will have a single RR. In that case, the cluster will be identified by the ROUTER_ID of the RR. However, this represents a single point of failure so to make it possible to have multiple RRs in the same cluster, all RRs in the same cluster can be configured with a 4-byte CLUSTER_ID so that an RR can discard routes from other RRs in the same cluster.
通常、クライアントのクラスタには、独身のRRがあるでしょう。 その場合、クラスタはRRのROUTER_IDによって特定されるでしょう。 しかしながら、これは、RRが同じクラスタで他のRRsからルートを捨てることができるように4バイトのCLUSTER_IDで同じクラスタで同じクラスタ、すべてのRRsに複数のRRsを持っているのを可能にするのを構成できるように1ポイントの失敗を表します。
Bates, et al. Standards Track [Page 5] RFC 2796 BGP Route Reflection April 2000
ベイツ、他 規格はBGPルート反射2000年4月にRFC2796を追跡します[5ページ]。
7. Avoiding Routing Information Loops
7. 経路情報輪を避けます。
When a route is reflected, it is possible through mis-configuration to form route re-distribution loops. The Route Reflection method defines the following attributes to detect and avoid routing information loops:
ルートが反映されるとき、ルート再分配輪を形成するのは誤構成を通して可能です。 方法が検出して、避けるために情報輪を発送しながら以下の属性を定義するRoute Reflection:
ORIGINATOR_ID
創始者_ID
ORIGINATOR_ID is a new optional, non-transitive BGP attribute of Type code 9. This attribute is 4 bytes long and it will be created by a RR in reflecting a route. This attribute will carry the ROUTER_ID of the originator of the route in the local AS. A BGP speaker should not create an ORIGINATOR_ID attribute if one already exists. A router which recognizes the ORIGINATOR_ID attribute should ignore a route received with its ROUTER_ID as the ORIGINATOR_ID.
ORIGINATOR_IDはTypeコード9の新しい任意の、そして、非他動なBGP属性です。 この属性は4バイト長です、そして、それはルートを反映する際にRRによって作成されるでしょう。 この属性は地方のASのルートの創始者のROUTER_IDを運ぶでしょう。 1つが既に存在するなら、BGPスピーカーはORIGINATOR_ID属性を作成するべきではありません。 ORIGINATOR_ID属性を認識するルータはROUTER_IDと共にORIGINATOR_IDとして受け取られたルートを無視するべきです。
CLUSTER_LIST
クラスタ_リスト
Cluster-list is a new optional, non-transitive BGP attribute of Type code 10. It is a sequence of CLUSTER_ID values representing the reflection path that the route has passed. It is encoded as follows:
クラスタリストはTypeコード10の新しい任意の、そして、非他動なBGP属性です。 それはルートが通り過ぎた反射経路を表すCLUSTER_ID値の系列です。 それは以下の通りコード化されます:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr. Flags |Attr. Type Code| Length | value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attr。 旗|Attr。 コードをタイプしてください。| 長さ| 値… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where Length is the number of octets.
Lengthが八重奏の数であるところ。
When a RR reflects a route, it must prepend the local CLUSTER_ID to the CLUSTER_LIST. If the CLUSTER_LIST is empty, it must create a new one. Using this attribute an RR can identify if the routing information is looped back to the same cluster due to mis- configuration. If the local CLUSTER_ID is found in the cluster-list, the advertisement received should be ignored.
RRがルートを反映すると、それは地方のCLUSTER_IDをCLUSTER_LISTにprependしなければなりません。CLUSTER_LISTが空であるなら、新しいものを作成しなければなりません。 この属性を使用して、RRは、ルーティング情報が誤構成のため同じクラスタに輪にして戻されるかどうか特定できます。 地方のCLUSTER_IDがクラスタリストで見つけられるなら、受け取られた広告は無視されるべきです。
8. Implementation Considerations
8. 実現問題
Care should be taken to make sure that none of the BGP path attributes defined above can be modified through configuration when exchanging internal routing information between RRs and Clients and Non-Clients. Their modification could potential result in routing loops.
RRsと、ClientsとNon-クライアントの間で内部のルーティング情報を交換するとき、構成を通して上で定義されたBGP経路属性のどれかを変更できないのを確実にするために注意するべきです。 潜在的結果が輪を中に発送して、彼らの変更はそうすることができました。
In addition, when a RR reflects a route, it should not modify the following path attributes: NEXT_HOP, AS_PATH, LOCAL_PREF, and MED. Their modification could potential result in routing loops.
さらに、RRがルートを反映すると、以下の経路属性を変更するべきではありません: _地方の_PREFの、そして、医学の経路としての次の_ホップ。 潜在的結果が輪を中に発送して、彼らの変更はそうすることができました。
Bates, et al. Standards Track [Page 6] RFC 2796 BGP Route Reflection April 2000
ベイツ、他 規格はBGPルート反射2000年4月にRFC2796を追跡します[6ページ]。
9. Configuration and Deployment Considerations
9. 構成と展開問題
The BGP protocol provides no way for a Client to identify itself dynamically as a Client of an RR. The simplest way to achieve this is by manual configuration.
BGPプロトコルはClientはRRのClientであるとダイナミックに名乗る方法を全く提供しません。 これを達成する最も簡単な方法は手動の構成を使用します。
One of the key component of the route reflection approach in addressing the scaling issue is that the RR summarizes routing information and only reflects its best path.
スケーリング問題を記述することにおける、ルート反射アプローチの主要なコンポーネントの1つはRRがルーティング情報をまとめて、最も良い経路を反映するだけであるということです。
Both MEDs and IGP metrics may impact the BGP route selection. Because MEDs are not always comparable and the IGP metric may differ for each router, with certain route reflection topologies the route reflection approach may not yield the same route selection result as that of the full IBGP mesh approach. A way to make route selection the same as it would be with the full IBGP mesh approach is to make sure that route reflectors are never forced to perform the BGP route selection based on IGP metrics which are significantly different from the IGP metrics of their clients, or based on incomparable MEDs. The former can be achieved by configuring the intra-cluster IGP metrics to be better than the inter-cluster IGP metrics, and maintaining full mesh within the cluster. The latter can be achieved by:
MEDsとIGP測定基準の両方がBGPルート選択に影響を与えるかもしれません。 MEDsがいつも匹敵しているというわけではなくて、IGPがメートル法であるので、各ルータのために異なるかもしれません、完全なIBGPについてアプローチを網の目にかけるルート反射アプローチが同じルート選択結果をもたらさないかもしれないあるルート反射topologiesで。 それが完全なIBGPメッシュアプローチと共にあるようにルート選択を同じにする方法はルート反射鏡が彼らのクライアントのIGP測定基準とかなり異なったIGP測定基準に基づいているか、または比較にならないほどMEDsに基づくBGPルート選択を決してやむを得ず実行しないのを確実にすることです。 イントラクラスタIGP測定基準が相互クラスタIGP測定基準より良いのを構成して、クラスタの中に完全なメッシュを維持することによって、前者を達成できます。 以下は後者を達成できます。
o setting the local preference of a route at the border router to
reflect the MED values.
o 境界ルータにおけるルートの地方の好みにMED値を反映するように設定します。
o or by making sure the AS-path lengths from different ASs are
different when the AS-path length is used as a route selection
criteria.
o AS-経路の長さがルート選択評価基準として使用されるとき、または、確実にすることによって、異なったASsからのAS-経路の長さは異なっています。
o or by configuring community based policies using which the
reflector can decide on the best route.
o または、共同体がどれを使用するかで方針を基礎づけたのを構成することによって、反射鏡は最も良いルートを決めることができます。
One could argue though that the latter requirement is overly restrictive, and perhaps impractical in some cases. One could further argue that as long as there are no routing loops, there are no compelling reasons to force route selection with route reflectors to be the same as it would be with the full IBGP mesh approach.
もっとも、1つは、いくつかの場合、後者の要件がひどく制限していて、恐らく非実用的であると主張するかもしれません。 1つは、ルーティング輪が全くない限り、それが完全なIBGPメッシュアプローチと共にあってルート反射鏡によるルート選択が同じであることを強制するやむにやまれない理由が全くないとさらに主張するかもしれません。
To prevent routing loops and maintain consistent routing view, it is essential that the network topology be carefully considered in designing a route reflection topology. In general, the route reflection topology should congruent with the network topology when there exist multiple paths for a prefix. One commonly used approach is the POP-based reflection, in which each POP maintains its own route reflectors serving clients in the POP, and all route reflectors are fully meshed. In addition, clients of the reflectors in each POP
輪を発送するのを防いで、一貫したルーティング視点を主張するために、ネットワーク形態がルート反射トポロジーを設計する際に慎重に考えられるのは、不可欠です。 一般に、ルート反射トポロジーは一致するべきです。接頭語のための複数の経路が存在するネットワーク形態について一致しています。 1つの一般的に使用されたアプローチがPOPベースの反映です、そして、すべてのルート反射鏡が完全に網の目にかけられます。(各POPはそれでPOPでクライアントに役立つそれ自身のルート反射鏡を維持します)。 添加、各POPの反射鏡のクライアントで
Bates, et al. Standards Track [Page 7] RFC 2796 BGP Route Reflection April 2000
ベイツ、他 規格はBGPルート反射2000年4月にRFC2796を追跡します[7ページ]。
are often fully meshed for the purpose of optimal intra-POP routing, and the intra-POP IGP metrics are configured to be better than the inter-POP IGP metrics.
最適のイントラPOPの目的のためにしばしば完全に網の目にかけられて、ルーティング、およびイントラ-POP IGP測定基準はそうです。相互POP IGP測定基準より良いのが構成されます。
10. Security Considerations
10. セキュリティ問題
This extension to BGP does not change the underlying security issues inherent in the existing IBGP [5].
BGPへのこの拡大は既存のIBGP[5]の固有である基本的な安全保障問題を変えません。
11. Acknowledgments
11. 承認
The authors would like to thank Dennis Ferguson, John Scudder, Paul Traina and Tony Li for the many discussions resulting in this work. This idea was developed from an earlier discussion between Tony Li and Dimitri Haskin.
作者はこの仕事をもたらす多くの議論についてデニスファーガソン、ジョンScudder、ポールTraina、およびトニー・李に感謝したがっています。 この考えはトニー・李とDimitriハスキンとの以前の議論から開発されました。
In addition, the authors would like to acknowledge valuable review and suggestions from Yakov Rekhter on this document, and helpful comments from Tony Li, Rohit Dube, and John Scudder on Section 9, and from Bruce Cole.
さらに、作者は、このドキュメントの上のヤコフRekhterから貴重なレビューと提案を承諾して、セクション9のトニー・李と、Rohitデュベと、ジョンScudderと、ブルース・コールから役に立つコメントを承諾したいです。
13. References
13. 参照
[1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[1]RekhterとY.と1995年のT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。
[2] Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh
routing", RFC 1863, October 1995.
[2] ハスキン、1995年10月、D.、「完全なメッシュルーティングへのBGP/IDRP Route Server代替手段」RFC1863。
[3] Traina, P., "Limited Autonomous System Confederations for BGP",
RFC 1965, June 1996.
[3]Traina、P.、「BGPのための株式会社の自律システム同盟者」、RFC1965、1996年6月。
[4] Bates, T. and R. Chandra, "BGP Route Reflection An alternative
to full mesh IBGP", RFC 1966, June 1996.
[4] ベイツとT.とR.チャンドラ、「完全なメッシュIBGPへのBGP Route Reflection An代替手段」、RFC1966、1996年6月。
[5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[5] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。
Bates, et al. Standards Track [Page 8] RFC 2796 BGP Route Reflection April 2000
ベイツ、他 規格はBGPルート反射2000年4月にRFC2796を追跡します[8ページ]。
14. Authors' Addresses
14. 作者のアドレス
Tony Bates Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
トニーベイツシスコシステムズInc.170の西タスマン・Driveサンノゼ、カリフォルニア 95134
EMail: tbates@cisco.com
メール: tbates@cisco.com
Ravi Chandra Redback Networks Inc. 350 Holger Way. San Jose, CA 95134
ラービーチャンドラ20ドル紙幣は株式会社350オルガーWayをネットワークでつなぎます。 サンノゼ、カリフォルニア 95134
EMail: rchandra@redback.com
メール: rchandra@redback.com
Enke Chen Redback Networks Inc. 350 Holger Way. San Jose, CA 95134
EnkeチェンRedbackは株式会社350オルガーWayをネットワークでつなぎます。 サンノゼ、カリフォルニア 95134
EMail: enke@redback.com
メール: enke@redback.com
Bates, et al. Standards Track [Page 9] RFC 2796 BGP Route Reflection April 2000
ベイツ、他 規格はBGPルート反射2000年4月にRFC2796を追跡します[9ページ]。
Appendix Comparison with RFC 1966
RFC1966との付録比較
Several terminologies related to route reflection are clarified, and the reference to EBGP routes/peers are removed.
ルート反射に関連するいくつかの用語をはっきりさせます、そして、EBGPルート/同輩についての言及を取り除きます。
The handling of a routing information loop (due to route reflection) by a receiver is clarified and made more consistent.
受信機によるルーティング情報輪(ルート反射による)の取り扱いをはっきりさせて、より一貫するようにします。
The addition of a CLUSTER_ID to the CLUSTER_LIST has been changed from "append" to "prepend" to reflect the deployed code.
CLUSTER_LISTへのCLUSTER_IDの添加は、配備されたコードを反映するために「追加」から"prepend"に変わりました。
The section on "Configuration and Deployment Considerations" has been expanded to address several operational issues.
「構成と展開問題」のセクションは、いくつかの操作上の問題を記述するために膨張しました。
Bates, et al. Standards Track [Page 10] RFC 2796 BGP Route Reflection April 2000
ベイツ、他 規格はBGPルート反射2000年4月にRFC2796を追跡します[10ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Bates, et al. Standards Track [Page 11]
ベイツ、他 標準化過程[11ページ]
一覧
スポンサーリンク
