RFC4456 日本語訳
4456 BGP Route Reflection: An Alternative to Full Mesh Internal BGP(IBGP). T. Bates, E. Chen, R. Chandra. April 2006. (Format: TXT=23209 bytes) (Obsoletes RFC2796, RFC1966) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Bates
Request for Comments: 4456 E. Chen
Obsoletes: 2796, 1966 Cisco Systems
Category: Standards Track R. Chandra
Sonoa Systems
April 2006
ネットワークワーキンググループT.はコメントを求める要求を和らげます: 4456 E.チェンは以下を時代遅れにします。 2796、1966シスコシステムズカテゴリ: 標準化過程R.チャンドラSonoaシステム2006年4月
BGP Route Reflection:
An Alternative to Full Mesh Internal BGP (IBGP)
BGPは反射を発送します: 完全なメッシュ内部のBGPへの代替手段(IBGP)
Status of This 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 (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for TCP/IP internets. Typically, 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 Autonomous System (AS). This represents a serious scaling problem that has been well documented with several alternatives proposed.
ボーダ・ゲイトウェイ・プロトコル(BGP)はTCP/IPインターネットのために設計された相互自律システムルーティング・プロトコルです。 通常、独身のASの中のすべてのBGPスピーカーを完全に網の目にかけなければならないので、そのAutonomous System(AS)の中の他のすべてのルータにどんな外部のルーティング情報も再配付しなければなりません。 これはいくつかの選択肢が提案されている状態でよく記録された重大なスケーリング問題を表します。
This document describes the use and design of a method known as "route reflection" to alleviate the need for "full mesh" Internal BGP (IBGP).
このドキュメントは、「完全なメッシュ」Internal BGP(IBGP)の必要性を軽減するために「ルート反射」として知られている方法の使用とデザインについて説明します。
This document obsoletes RFC 2796 and RFC 1966.
このドキュメントはRFC2796とRFC1966を時代遅れにします。
Bates, et al. Standards Track [Page 1] RFC 4456 BGP Route Reflection April 2006
ベイツ、他 規格はBGPルート反射2006年4月にRFC4456を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................2
2. Specification of Requirements ...................................2
3. Design Criteria .................................................3
4. Route Reflection ................................................3
5. Terminology and Concepts ........................................4
6. Operation .......................................................5
7. Redundant RRs ...................................................6
8. Avoiding Routing Information Loops ..............................6
9. Impact on Route Selection .......................................7
10. Implementation Considerations ..................................7
11. Configuration and Deployment Considerations ....................7
12. Security Considerations ........................................8
13. Acknowledgements ...............................................9
14. References .....................................................9
14.1. Normative References ......................................9
14.2. Informative References ....................................9
Appendix A: Comparison with RFC 2796 ..............................10
Appendix B: Comparison with RFC 1966 ..............................10
1. 序論…2 2. 要件の仕様…2 3. 評価基準を設計してください…3 4. 反射を発送してください…3 5. 用語と概念…4 6. 操作…5 7. 余分なRRs…6 8. 経路情報を避けるのは輪にされます…6 9. ルート選択のときに、影響を与えてください…7 10. 実現問題…7 11. 構成と展開問題…7 12. セキュリティ問題…8 13. 承認…9 14. 参照…9 14.1. 標準の参照…9 14.2. 有益な参照…9 付録A: RFC2796との比較…10 付録B: RFC1966との比較…10
1. Introduction
1. 序論
Typically, 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 Internal BGP (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 today's networks.
通常、独身のASの中のすべてのBGPスピーカーを完全に網の目にかけなければなりません、そして、そのASの中の他のすべてのルータにどんな外部のルーティング情報も再配付しなければなりません。 それがn*(n-1)/2のユニークなInternal BGP(IBGP)セッションを維持するのを必要とするASの中のn BGPスピーカーのために。 それぞれ今日のネットワークの多くで一般的にそのままな多くのルーティング情報を交換する多くのIBGPスピーカーがいるとき、この「完全なメッシュ」要件は明確に比例しません。
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 a "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 non-transitive BGP attributes to prevent loops in routing updates.
このスケーリング問題をよく記録しました、そして、これ[2、3]を軽減するのを多くの提案をしました。 このドキュメントは、「完全なメッシュ」の必要性を軽減する際に別の代替手段を表して、「ルート反射」として知られています。 このアプローチで、BGPスピーカー(「ルート反射鏡」として、知られている)は確信しているIBGP同輩にIBGPの学術的ルートの広告を出すことができます。 それはIBGPの一般的に理解されている概念における変化を表します、そして、防ぐ2つの新しい任意の非他動詞BGP属性の添加はルーティングアップデートで輪にされます。
This document obsoletes RFC 2796 [6] and RFC 1966 [4].
このドキュメントはRFC2796[6]とRFC1966[4]を時代遅れにします。
2. Specification of Requirements
2. 要件の仕様
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [7].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[7]で説明されるように本書では解釈されることであるべきですか?
Bates, et al. Standards Track [Page 2] RFC 4456 BGP Route Reflection April 2006
ベイツ、他 規格はBGPルート反射2006年4月にRFC4456を追跡します[2ページ]。
3. Design Criteria
3. 設計基準
Route reflection was designed to satisfy the following criteria.
ルート反射は、以下の評価基準を満たすように設計されました。
o Simplicity
o 簡単さ
Any alternative must be simple to configure and easy to
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 noncompliant IBGP peers to continue to
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.
これらの評価基準は多くの外部の接続による非常に大きくてトポロジー豊富なネットワークの運用経験で動機づけられました。
4. Route Reflection
4. ルート反射
The basic idea of route reflection is very simple. Let us consider the simple example depicted in Figure 1 below.
ルート反射の基本的な考え方は非常に簡単です。 以下の図1に表現された簡単な例を考えましょう。
+-------+ +-------+
| | 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
ASXに、3人のIBGPスピーカー(ルータRTR-A、RTR-B、およびRTR-C)がいます。 存在で、RTR-Aが外部を受けるなら、BGPはモデル化します。
Bates, et al. Standards Track [Page 3] RFC 4456 BGP Route Reflection April 2006
ベイツ、他 規格はBGPルート反射2006年4月にRFC4456を追跡します[3ページ]。
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.
ルートと最も良い経路として選択されて、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.
ルート反射計画はこの基本原理に基づいています。
5. Terminology and Concepts
5. 用語と概念
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 an RR are divided into two groups:
RRの内部の同輩は2つのグループに分割されます:
1) Client peers
1) クライアント同輩
2) Non-Client peers
2) 非クライアント同輩
An RR reflects routes between these groups, and may reflect routes among client peers. An 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はクラスタを形成します。 Non-クライアント同輩を完全に網の目にかけなければなりませんが、Client同輩は完全に網の目にかけられなければならないというわけではありません。 図3は上に述べられた用語を使用することで基本的なRRの部品について概説する簡単な例について表現します。
Bates, et al. Standards Track [Page 4] RFC 4456 BGP Route Reflection April 2006
ベイツ、他 規格はBGPルート反射2006年4月にRFC4456を追跡します[4ページ]。
/ - - - - - - - - - - - - - -
| 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の部品
6. Operation
6. 操作
When an 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 peer it is receiving the best path from
RRがIBGP同輩からルートを受けるとき、それは経路選択規則に基づく中で最も良い経路を選択します。 最も良い経路が選択された後に、それは受けている中で経路最も良い同輩のタイプで以下の依存をしなければなりません。
1) A route from a Non-Client IBGP peer:
1) Non-クライアントIBGP同輩からのルート:
Reflect to all the Clients.
すべてのClientsに反射してください。
2) A route from a Client peer:
2) Client同輩からのルート:
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. An RR treats other RRs just like any other internal BGP speakers. An 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を構成できました。
Bates, et al. Standards Track [Page 5] RFC 4456 BGP Route Reflection April 2006
ベイツ、他 規格はBGPルート反射2006年4月にRFC4456を追跡します[5ページ]。
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 an 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 coexist. Conventional BGP speakers could be members of either 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では、ルート反射鏡の概念を理解していないBGPスピーカーがいるのは、可能です(それらを従来のBGPスピーカーと呼びましょう)。 ルート反射鏡計画で、そのような従来のBGPスピーカーは共存できます。 従来のBGPスピーカーはNon-クライアントグループかClientグループのどちらかのメンバーであるかもしれません。 これは簡単でゆるやかな現在のIBGPモデルからルート反射モデルまでの移動を考慮します。 1つは、指定されたRRとしてただ一つのルータを構成して、正常なIBGPがじっと見るので他のRRsと彼らのクライアントを構成することによってクラスタを作成し始めるかもしれません。 徐々に追加クラスタを作成できます。
7. Redundant RRs
7. 余分なRRs
Usually, a cluster of clients will have a single RR. In that case, the cluster will be identified by the BGP Identifier 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のBGP Identifierによって特定されるでしょう。 しかしながら、これは、RRが同じクラスタで他のRRsからルートを捨てることができるように4バイトのCLUSTER_IDで同じクラスタで同じクラスタ、すべてのRRsに複数のRRsを持っているのを可能にするのを構成できるように1ポイントの失敗を表します。
8. Avoiding Routing Information Loops
8. 経路情報輪を避けます。
When a route is reflected, it is possible through misconfiguration to form route re-distribution loops. The route reflection method defines the following attributes to detect and avoid routing information loops:
ルートが反映されるとき、ルート再分配輪を形成するのはmisconfigurationを通して可能です。 反射法が検出して、避けるために情報輪を発送しながら以下の属性を定義するルート:
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 an RR in reflecting a route. This attribute will carry the BGP Identifier 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 that recognizes the ORIGINATOR_ID attribute SHOULD ignore a route received with its BGP Identifier as the ORIGINATOR_ID.
ORIGINATOR_IDはTypeコード9の新しい任意の、そして、非他動なBGP属性です。 この属性は4バイト長です、そして、それはルートを反映する際にRRによって作成されるでしょう。 この属性は地方のASのルートの創始者のBGP Identifierを運ぶでしょう。 1つが既に存在しているなら、BGPスピーカーSHOULD NOTはORIGINATOR_ID属性を作成します。 ORIGINATOR_ID属性SHOULDがルートを無視すると認めるルータはBGP Identifierと共にORIGINATOR_IDとして受信されました。
Bates, et al. Standards Track [Page 6] RFC 4456 BGP Route Reflection April 2006
ベイツ、他 規格はBGPルート反射2006年4月にRFC4456を追跡します[6ページ]。
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.
CLUSTER_LISTはTypeコード10の新しくて、任意の非他動詞BGP属性です。 それはルートが通り過ぎた反射経路を表すCLUSTER_ID値の系列です。
When an 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 has looped back to the same cluster due to misconfiguration. 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は、misconfigurationのためルーティング情報が同じクラスタに輪にして戻られたかどうか特定できます。 _IDは地方のCLUSTERであるならCLUSTER_LISTで当たられて、広告はSHOULDを受けました。無視されます。
9. Impact on Route Selection
9. ルート選択のときに、影響を与えてください。
The BGP Decision Process Tie Breaking rules (Sect. 9.1.2.2, [1]) are modified as follows:
BGP Decision Process Tie Breaking規則(セクト。 9.1.2.2, [1]) 以下の通り変更されます:
If a route carries the ORIGINATOR_ID attribute, then in Step f)
the ORIGINATOR_ID SHOULD be treated as the BGP Identifier of the
BGP speaker that has advertised the route.
ルートがORIGINATOR_ID属性を運ぶなら、Step f) ORIGINATOR_ID SHOULDでは、ルートの広告を出したBGPスピーカーのBGP Identifierとして扱われてください。
In addition, the following rule SHOULD be inserted between Steps
f) and g): a BGP Speaker SHOULD prefer a route with the shorter
CLUSTER_LIST length. The CLUSTER_LIST length is zero if a route
does not carry the CLUSTER_LIST attribute.
さらに、以下が、SHOULDがSteps fの間に挿入されると裁決する、)、g): BGP SHOULD議長は、より短いCLUSTER_LISTの長さがあるルートを好みます。 ルートがCLUSTER_LIST属性を運ばないなら、CLUSTER_LISTの長さはゼロです。
10. Implementation Considerations
10. 実現問題
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 potentially 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 potentially result in routing loops.
添加では、以下の経路属性を変更してください:(その時、RRはルートを反映して、それはSHOULD NOTです)。 _地方の_PREFの、そして、医学の経路としての次の_ホップ。 彼らの変更は潜在的にルーティング輪をもたらすかもしれません。
11. Configuration and Deployment Considerations
11. 構成と展開問題
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がルーティング情報をまとめて、最も良い経路を反映するだけであるということです。
Bates, et al. Standards Track [Page 7] RFC 4456 BGP Route Reflection April 2006
ベイツ、他 規格はBGPルート反射2006年4月にRFC4456を追跡します[7ページ]。
Both Multi-Exit Discriminators (MEDs) and Interior Gateway Protocol (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 that 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
Multi-出口Discriminators(MEDs)とInteriorゲートウェイプロトコル(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, or
o または境界ルータにおけるルートの地方の好みにMED値を反映するように設定する。
o making sure the AS-path lengths from different ASes are
different when the AS-path length is used as a route selection
criteria, or
o またはAS-経路の長さがルート選択評価基準として使用されるとき、確実にして、異なったASesからのAS-経路の長さが異なっている。
o configuring community-based policies to influence the route
selection.
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 be congruent with the network topology when there exist multiple paths for a prefix. One commonly used approach is the reflection based on Point of Presence (POP), 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 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.
輪を発送するのを防いで、一貫したルーティング視点を主張するために、ネットワーク形態がルート反射トポロジーを設計する際に慎重に考えられるのは、不可欠です。 接頭語のための複数の経路が存在するとき、一般に、ルート反射トポロジーはネットワーク形態について一致しているべきです。 1つの一般的に使用されたアプローチが各POPがPOPでクライアントに役立つそれ自身のルート反射鏡を維持するPresence(POP)のPointに基づく反映です、そして、すべてのルート反射鏡が完全に網の目にかけられます。 さらに、各POPの反射鏡のクライアントは最適のイントラPOPルーティングの目的のためにしばしば完全に網の目にかけられます、そして、イントラ-POP IGP測定基準は、相互POP IGP測定基準より良くなるように構成されます。
12. Security Considerations
12. セキュリティ問題
This extension to BGP does not change the underlying security issues inherent in the existing IBGP [1, 5].
BGPへのこの拡大は既存のIBGP[1、5]の固有である基本的な安全保障問題を変えません。
Bates, et al. Standards Track [Page 8] RFC 4456 BGP Route Reflection April 2006
ベイツ、他 規格はBGPルート反射2006年4月にRFC4456を追跡します[8ページ]。
13. Acknowledgements
13. 承認
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, John Scudder, and Bruce Cole.
さらに、作者は、このドキュメントの上のヤコフRekhterから貴重なレビューと提案を承諾して、トニー・李、Rohitデュベ、ジョンScudder、およびブルース・コールから役に立つコメントを承諾したいです。
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[1] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4
(BGP-4)", RFC 4271, January 2006.
[1]Rekhter、Y.、李、T.、およびS.野兎、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC4271 2006年1月。
14.2. Informative References
14.2. 有益な参照
[2] Savola, P., "Reclassification of RFC 1863 to Historic", RFC
4223, October 2005.
[2]Savola、P.、「Reclassification、歴史的へのRFC1863、」、RFC4223、10月2005日
[3] Traina, P., McPherson, D., and J. Scudder, "Autonomous System
Confederations for BGP", RFC 3065, February 2001.
2001年2月の[3]TrainaとP.とマクファーソン、D.とJ.Scudder、「BGPのための自律システム同盟者」RFC3065。
[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月。
[6] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An
Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[6] ベイツ、T.、チャンドラ、R.、およびE.チェン、「BGPは反射を発送します--完全なメッシュIBGPへの代替手段」、RFC2796、2000年4月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Bates, et al. Standards Track [Page 9] RFC 4456 BGP Route Reflection April 2006
ベイツ、他 規格はBGPルート反射2006年4月にRFC4456を追跡します[9ページ]。
Appendix A: Comparison with RFC 2796
付録A: RFC2796との比較
The impact on route selection is added.
ルート選択への影響は加えられます。
The pictorial description of the encoding of the CLUSTER_LIST attribute is removed as the description is redundant to the BGP specification, and the attribute length field is inadvertently described as one octet.
記述がBGP仕様に余分であるので、CLUSTER_LIST属性のコード化の絵による描写は移されます、そして、属性長さの野原はうっかり1つの八重奏として記述されています。
Appendix B: Comparison with RFC 1966
付録B: RFC1966との比較
All the changes listed in Appendix A, plus the following.
すべての変化がAppendix A、および以下に記載しました。
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 4456 BGP Route Reflection April 2006
ベイツ、他 規格はBGPルート反射2006年4月にRFC4456を追跡します[10ページ]。
Authors' Addresses
作者のアドレス
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 Sonoa Systems, Inc. 3255-7 Scott Blvd. Santa Clara, CA 95054
ラービーチャンドラSonoaシステムInc.3255-7スコットBlvd. サンタクララ、カリフォルニア 95054
EMail: rchandra@sonoasystems.com
メール: rchandra@sonoasystems.com
Enke Chen Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
EnkeチェンシスコシステムズInc.170の西タスマン・Driveサンノゼ、カリフォルニア 95134
EMail: enkechen@cisco.com
メール: enkechen@cisco.com
Bates, et al. Standards Track [Page 11] RFC 4456 BGP Route Reflection April 2006
ベイツ、他 規格はBGPルート反射2006年4月にRFC4456を追跡します[11ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Bates, et al. Standards Track [Page 12]
ベイツ、他 標準化過程[12ページ]
一覧
スポンサーリンク
