RFC4264 日本語訳

4264 BGP Wedgies. T. Griffin, G. Huston. November 2005. (Format: TXT=24139 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                         T. Griffin
Request for Comments: 4264                       University of Cambridge
Category: Informational                                        G. Huston
                                                                   APNIC
                                                           November 2005

コメントを求めるワーキンググループT.グリフィンの要求をネットワークでつないでください: 4264年のケンブリッジ大学カテゴリ: 情報のG.ヒューストンAPNIC2005年11月

                              BGP Wedgies

BGP Wedgies

Status of this Memo

この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 (2005).

Copyright(C)インターネット協会(2005)。

Abstract

要約

   It has commonly been assumed that the Border Gateway Protocol (BGP)
   is a tool for distributing reachability information in a manner that
   creates forwarding paths in a deterministic manner.  In this memo we
   will describe a class of BGP configurations for which there is more
   than one potential outcome, and where forwarding states other than
   the intended state are equally stable.  Also, the stable state where
   BGP converges may be selected by BGP in a non-deterministic manner.
   These stable, but unintended, BGP states are termed here "BGP
   Wedgies".

ボーダ・ゲイトウェイ・プロトコル(BGP)が決定論的な方法で推進経路を作成する方法による可到達性情報を分配するためのツールであると一般的に思われました。 このメモでは、私たちは1つ以上の潜在的結果があって、意図している状態以外の推進州が等しく安定しているBGP構成のクラスについて説明するつもりです。 また、BGPが一点に集まる安定した状態は非決定論的な方法でBGPによって選択されるかもしれません。 これらの安定しましたが、故意でないBGP州はここに呼ばれます。「BGP Wedgies。」

Table of Contents

目次

   1. Introduction ....................................................2
   2. Describing BGP Routing Policy ...................................2
   3. BGP Wedgies .....................................................3
   4. Multi-Party BGP Wedgies .........................................6
   5. BGP and Determinism .............................................7
   6. Security Considerations .........................................8
   7. References ......................................................9
      7.1. Normative References .......................................9
      7.2. Informative References .....................................9

1. 序論…2 2. BGPルート設定方針を説明します…2 3. BGP Wedgies…3 4. マルチパーティBGP Wedgies…6 5. BGPと決定論…7 6. セキュリティ問題…8 7. 参照…9 7.1. 標準の参照…9 7.2. 有益な参照…9

Griffin & Huston             Informational                      [Page 1]

RFC 4264                      BGP Wedgies                  November 2005

[1ページ]RFC4264BGP Wedgies2005年11月の情報のグリフィンとヒューストン

1.  Introduction

1. 序論

   It has commonly been assumed that the Border Gateway Protocol (BGP)
   [RFC1771] is a tool for distributing reachability information in a
   manner that creates forwarding paths in a deterministic manner.  This
   is a 'problem statement' memo that describes a class of BGP
   configurations for which there is more than one stable forwarding
   state.  In this class of configurations there exist multiple stable
   forwarding states.  One of these stable forwarding states is the
   intended state, with other stable forwarding states being unintended.
   The BGP convergence process of selection of a stable forwarding state
   may operate in a non-deterministic manner in such cases.

ボーダ・ゲイトウェイ・プロトコル(BGP)[RFC1771]が決定論的な方法で推進経路を作成する方法による可到達性情報を分配するためのツールであると一般的に思われました。 これは1つ以上の安定した推進州があるBGP構成のクラスについて説明する'問題声明'メモです。 このクラスの構成では、複数の安定した推進州が存在しています。 これらの安定した推進州の1つは他の安定した推進州が故意でない意図している状態です。 安定した推進状態の選択のBGP集合の過程は非決定論的な方法でそのような場合作動するかもしれません。

   These stable, but unintended, BGP states are termed here "BGP
   Wedgies".

これらの安定しましたが、故意でないBGP州はここに呼ばれます。「BGP Wedgies。」

2.  Describing BGP Routing Policy

2. BGPルート設定方針を説明します。

   BGP routing policies generally reflect each network administrator's
   objective to optimize their position with respect to their network's
   cost, performance, and reliability.

一般に、BGPルーティング方針は、それらのネットワークの費用、性能、および信頼性に関してそれらの位置を最適化するためにそれぞれネットワークアドミニストレータの目的を反映します。

   With respect to cost optimization, the local network's default
   routing policy often reflects a local preference to prefer routes
   learned from a customer to routes learned from some form of peering
   exchange.  In the same vein, the local network is often configured to
   prefer routes learned from a peer or a customer over those learned
   from a directly connected upstream transit provider.  These
   preferences may be expressed via a local preference configuration
   setting, where the local preference overrides the AS path length
   metric of the base BGP operation.

費用最適化に関して、企業内情報通信網のデフォルトルーティング方針は、顧客から何らかの形式のじっと見る交換から学習されたルートまで学習されたルートを好むためにしばしば地方の優先を反映します。 同じ流れでは、企業内情報通信網は、直接接続された上流のトランジットプロバイダーから学習されたものの上で同輩か顧客から学習されたルートを好むためにしばしば構成されます。 これらの好みは地方の好みの構成設定で言い表されるかもしれません。そこでは、地方の好みがベースBGP操作におけるメートル法のAS経路の長さをくつがえします。

   In terms of engineering reliability in the inter-domain routing
   environment it is commonly the case that a service provider may enter
   into arrangements with two or more upstream transit providers,
   passing routes to all upstream providers, and receiving traffic from
   all sources.  If the path to one upstream fails, the traffic will
   switch to other links.  Once the path is recovered, the traffic
   should switch back.

相互ドメインルーティング環境における工学の信頼性に関して、サービスプロバイダーが2つ以上の上流のトランジットプロバイダーと共にアレンジメントに入るかもしれないのは、一般的に事実です、すべての上流のプロバイダーにルートを移って、すべてのソースから交通を受けて。 1つの上流への経路が失敗すると、交通は他のリンクに切り替わるでしょう。 経路がいったん回復されると、交通は元に戻るべきです。

   In such situations of multiple upstream providers it is also common
   to place a relative preference on the providers, so that one
   connection is regarded as a preferred, or "primary" connection, and
   other connections are regarded as less preferred, or "backup"
   connections.  The intent is typically that the backup connections
   will be used for traffic only for the duration of a failure in the
   primary connection.

また、複数の上流のプロバイダーのそのような状況で、プロバイダーに相対的選好を置くのも一般的です、1つの接続が都合のよいか、または「第一」の接続と見なされて、他の接続がそれほど好まれないように見なされるか、または接続の「バックアップをとる」ように。 意図は通常、バックアップ接続が第一の接続における失敗の持続時間のためだけの交通に使用されるということです。

Griffin & Huston             Informational                      [Page 2]

RFC 4264                      BGP Wedgies                  November 2005

[2ページ]RFC4264BGP Wedgies2005年11月の情報のグリフィンとヒューストン

   It is possible to express this primary / backup policy using local AS
   path prepending, where the AS path is artificially lengthened towards
   the backup providers, using additional instances of the local AS.
   This is not a deterministic selection algorithm, as the selected
   primary provider may in turn be using AS path prepending to its
   backup upstream provider, and in certain cases the path through the
   backup provider may still be selected as the shortest AS path length.

AS経路が人工的にバックアッププロバイダーに向かって伸される地方のAS経路prependingを使用するこの予備選挙/バックアップ方針を言い表すのは可能です、地方のASの追加例を使用して。 これが決定論的な選択アルゴリズムでない、選択された第一のプロバイダーが順番にAS経路を使用しているとき、バックアップ上流にプロバイダーをprependingして、ある場合には、バックアッププロバイダーを通して経路をprependingするのは最も短いAS経路の長さとしてまだ選定されているかもしれません。

   An alternative approach to routing policy specification uses BGP
   communities [RFC1997].  In this case, the provider publishes a set of
   community values that allows the client to select the provider's
   local preference setting.  The client can use a community to mark a
   route as "backup only" towards the backup provider, and "primary
   preferred' to the primary provider, assuming both providers support
   community values with such semantics.  In this case, the local
   preference overrides the AS path length metric, so that if the route
   is marked "backup only", the route will be selected only when there
   is no other source of the route.

ルーティング方針仕様への代替的アプローチはBGP共同体[RFC1997]を使用します。 この場合、プロバイダーはクライアントがプロバイダーの地方の好みの設定を選択できる1セットの共同体値を発行します。 'クライアントはバックアッププロバイダーに向かった「バックアップ専用」としてルートをマークして、「好まれた予備選挙'を第一のプロバイダーにマークするのに共同体を使用できます、両方のプロバイダーがそのような意味論があるサポート共同体値であると仮定して」。 この場合、地方の好みはメートル法でAS経路の長さをくつがえします、ルートの他の源が全くないときだけ、ルートが「バックアップ専用」であるとマークされると、ルートが選択されるように。

3.  BGP Wedgies

3. BGP Wedgies

   The richness of local policy expression through the use of
   communities, when coupled with the behavior of a distance vector
   protocol like BGP, leads to the observation that certain
   configurations have more than one "solution", or more than one stable
   BGP state.  An example of such a situation is indicated in Figure 1.

BGPのような距離ベクトルプロトコルの振舞いに結びつけられると、共同体の使用による地方の方針表現の豊かはある構成には1「解決策」、または1つ以上の安定したBGP州があるという観測につながります。 そのような状況に関する例は図1で示されます。

       +----+peer                peer+----+
       |AS 3|------------------------|AS 4|
       +----+                        +----+
         |provider             provider|
         |                             |
         |                             |
         |customer                     |
       +----+                          |
       |AS 2|                          |
       +----+                          |
         |provider                     |
         |                             |
         |                             |
         |customer             customer|
         +---------------+  +----------+
           backup service|  |primary service
                        +----+
                        |AS 1|
                        +----+

+----+ 同輩同輩+----+ |3として|------------------------|4として| +----+ +----+ |プロバイダープロバイダー| | | | | |顧客| +----+ | |2として| | +----+ | |プロバイダー| | | | | |顧客顧客| +---------------+ +----------+ アフターサービス| |一次業務+----+ |1として| +----+

                                 Figure 1

図1

Griffin & Huston             Informational                      [Page 3]

RFC 4264                      BGP Wedgies                  November 2005

[3ページ]RFC4264BGP Wedgies2005年11月の情報のグリフィンとヒューストン

   In this case, AS1 has marked its advertisement of prefixes to AS2 as
   "backup only", and its advertisement of prefixes to AS4 as "primary".
   AS4 will advertise AS1's prefixes to AS3.  AS3 will hear AS4's
   advertisement across the peering link, and select AS1's prefixes with
   the path "AS4, AS1".  AS3 will advertise these prefixes to AS2.  AS2
   will hear two paths to AS1's prefixes, the first is via the direct
   connection to AS1, and the second is via the path "AS3, AS4, AS1".
   AS2 will prefer the longer path, as the directly connected routes are
   marked "backup only", and AS2's local preference decision will prefer
   the AS3 advertisement over the AS1 advertisement.

この場合、AS1は、「バックアップ専用」としてのAS2への接頭語の広告、およびAS4への接頭語のその広告が「第一である」とマークしました。 AS4はAS1の接頭語のAS3に広告を出すでしょう。 AS3はじっと見るリンクの向こう側にAS4の広告を聞いて、経路「AS4、AS1"」と共にAS1の接頭語を選択するでしょう。 AS3はこれらの接頭語のAS2に広告を出すでしょう。 AS2は2つの経路をAS1の接頭語に聞くでしょう、そして、1番目がAS1とのダイレクト接続であります、そして、経路「AS3、AS4、AS1"」を通して2番目があります。 AS2は、より長い経路を好むでしょう、直接接続されたルートが「バックアップ専用」であるとマークされて、AS2のローカルの好みの決定がAS1広告の上のAS3広告を好むとき。

   This is the intended outcome of AS1's policy settings where, in the
   'normal' state, no traffic passes from AS2 to AS1 across the backup
   link, and AS2 reaches AS1 via a path that transits AS3 and AS4, using
   the primary link to AS1.

AS1への第一のリンクを使用して、これはAS2範囲の交通が全くバックアップリンクの向こう側に'正常な'状態では、AS2からAS1まで通り過ぎないAS1の方針設定、経路を通したAS3を通過するAS1、およびAS4の意図している結果です。

   This intended outcome is achieved as long as AS1 announces its routes
   on the primary path to AS4 before announcing its backup routes to
   AS2.

バックアップルートをAS2に発表する前にAS1が第一の経路のルートをAS4に発表する限り、この意図している結果は獲得されます。

   If the AS1 - AS4 path is broken, causing a BGP session failure
   between AS1 and AS4, then AS4 will withdraw its advertisement of
   AS1's routes to AS3, who, in turn, will send a withdrawal to AS2.
   AS2 will then select the backup path to AS1.  AS2 will advertise this
   path to AS3, and AS3 will advertise this path to AS4.  Again, this is
   part of the intended operation of the primary / backup policy
   setting, and all traffic to AS1 will use the backup path.

AS1--AS1とAS4の間のBGPセッションの故障を引き起こして、AS4経路が起伏が多い、そして、AS4はAS1のルートに関する広告をAS3に引き下がらせるでしょう。(順番に、AS3は退出をAS2に送るでしょう)。 そして、AS2はバックアップ道をAS1に選択するでしょう。 AS2はこの経路のAS3に広告を出すでしょう、そして、AS3はこの経路のAS4に広告を出すでしょう。 一方、これは予備選挙/バックアップ方針設定の意図している操作の一部です、そして、AS1へのすべての交通がバックアップ道を使用するでしょう。

   When connectivity between AS4 and AS1 is restored the BGP state will
   not revert to the original state.  AS4 will learn the primary path to
   AS1 and re-advertise this to AS3 using the path "AS4, AS1".  AS3,
   using a default preference of preferring customer-advertised routes
   over peer routes will continue to prefer the "AS2, AS1" path.  AS3
   will not pass any updates to AS2.  After the restoration of the
   AS4-to-AS1 circuit, the traffic from AS3 to AS1 and from AS2 to AS1
   will be presented to AS1 via the backup path, even through the
   primary path via AS4 is back in service.

AS4とAS1の間の接続性が回復するとき、BGP状態は原状に戻らないでしょう。 AS4は、経路「AS4、AS1"」を使用することで第一の経路をAS1に学んで、AS3にこれの再広告を出すでしょう。 AS3、同輩ルートより顧客によって広告を出されたルートを好むデフォルト優先を使用するのは「AS2、AS1"経路」を好み続けるでしょう。 AS3はどんなアップデートもAS2に通過しないでしょう。 AS4からAS1へのサーキットの修復の後に、AS3からAS1までAS2からAS1までの交通はバックアップ道を通ってAS1に提示されて、AS4を通した第一の経路さえを通して、サービスにおける後部があります。

   The intended forwarding state can only be restored by AS1
   deliberately bringing down its eBGP session with AS2, even though it
   is carrying traffic.  This will cause the BGP state to revert to the
   intended configuration.

故意にAS2とのeBGPセッションを降ろすAS1は意図している推進状態を回復できるだけです、交通を運びますが。 これで、BGP状態は意図している構成に戻るでしょう。

   It is often the case that an AS will attempt to balance incoming
   traffic across multiple providers, again using the primary / backup
   mechanism.  For some prefixes one link is configured as the primary
   link, and the others as the backup link, while for other prefixes
   another link is selected as the primary link.  An example is shown in

しばしば、ASは、複数のプロバイダーの向こう側に入って来る交通のバランスをとるのを試みるでしょう、再び予備選挙/バックアップメカニズムを使用して。 いくつかの接頭語において、1個のリンクが第一のリンクとして構成されます、そして、バックアップとしての他のものはリンクします、別のリンクが第一のリンクとして他の接頭語において選定されますが。 例では、目立ちます。

Griffin & Huston             Informational                      [Page 4]

RFC 4264                      BGP Wedgies                  November 2005

[4ページ]RFC4264BGP Wedgies2005年11月の情報のグリフィンとヒューストン

   Figure 2.

図2。

       +----+peer                  peer+----+
       |AS 3|--------------------------|AS 4|
       +----+                          +----+
         |provider               provider|
         |                               |
         |                       customer|
         |customer                       |
       +----+                          +----+
       |AS 2|                          |AS 5|
       +----+                          +----+
         |provider               provider|
         |                               |
         |                               |
         |customer               customer|
         +-----------------+  +----------+
                           |  |
    backup (192.0.2.0/25)  |  |primary service (192.0.2.0/25)
   primary (192.0.2.128/25)|  |backup service (192.0.2.128/25)
                          +----+
                          |AS 1|
                          +----+

+----+ 同輩同輩+----+ |3として|--------------------------|4として| +----+ +----+ |プロバイダープロバイダー| | | | 顧客| |顧客| +----+ +----+ |2として| |5として| +----+ +----+ |プロバイダープロバイダー| | | | | |顧客顧客| +-----------------+ +----------+ | | バックアップ、(192.0、.2、.0/25)| |一次業務、(192.0.2 25).0/予備選挙、(192.0、.2、.128/25)| |アフターサービス、(192.0、.2 25).128/+----+ |1として| +----+

                                 Figure 2

図2

   The intended configuration has all incoming traffic for addresses in
   the range 192.0.2.0/25 via the link from AS5, and all incoming
   traffic for addresses in the range 192.0.2.128/25 from AS2.

意図している構成は範囲192.0にアドレスのためのすべての入って来る交通を持っています。.2 .0 AS5、およびすべての入来からのリンクを通した/25はアドレスのためにAS2から範囲192.0.2で.128/25を取引します。

   In this case, if the link between AS3 and AS4 is reset, AS3 will
   learn both routes from AS2, and AS4 will learn both routes from AS5.
   As these customer routes are preferred over peer routes, when the
   link between AS3 and AS4 is restored, neither AS3 nor AS4 will alter
   their routing behavior with respect to AS1's routes.  This situation
   is now wedged, in that there is no eBGP peering that can be reset
   that will flip BGP back to the intended state.  This is an instance
   of a BGP Wedgie.

この場合、AS3とAS4は間のリンクであるならリセットされます、そして、AS3はAS2から両方のルートを学ぶでしょう、そして、AS4はAS5から両方のルートを学ぶでしょう。 AS3とAS4とのリンクが返されるとき、これらの顧客ルートが同輩ルートより好まれるように、AS3もAS4もAS1のルートに関して彼らのルーティングの振舞いを変更しないでしょう。 いいえ、じっと見るeBGPがあるので、意図している状態にBGPをはじき出して戻すリセットであるかもしれないこの状況は現在、くさびで留められます。 これはBGP Wedgieの例です。

   The restoration path here is that AS1 has to withdraw the backup
   advertisements on both paths and operate for an interval without
   backup, and then re-advertise the backup prefix advertisements.  The
   length of the interval cannot be readily determined in advance, as it
   has to be sufficiently long so as to allow AS2 and AS5 to learn of an
   alternate path to AS1.  At this stage the backup routes can be re-
   advertised.

ここの回復経路はAS1が両方の経路でバックアップ広告を引き下がらせて、間隔の間、バックアップなしで作動して、次に、バックアップ接頭語広告の再広告を出さなければならないということです。 あらかじめ容易に間隔の長さを測定できません、それがAS2とAS5が代替パスをAS1に知るのを許容するために十分長くなければならないときに。 現在のところ、バックアップルートの再広告を出すことができます。

Griffin & Huston             Informational                      [Page 5]

RFC 4264                      BGP Wedgies                  November 2005

[5ページ]RFC4264BGP Wedgies2005年11月の情報のグリフィンとヒューストン

4.  Multi-Party BGP Wedgies

4. マルチパーティBGP Wedgies

   This situation can be more complex when three or more parties provide
   upstream transit services to an AS.  An example is indicated in
   Figure 3.

3回以上のパーティーがASに対する上流のトランジットサービスを提供するとき、この状況は、より複雑である場合があります。 例は図3で示されます。

       +----+ peer              peer +----+
       |AS 3|------------------------|AS 4|
       +----+                        +----+
        ||provider             provider|
        |+----------------+            |
        |                 |            |
        |customer         |customer    |
       +----+peer   peer+----+         |
       |AS 2|-----------|AS 5|         |
       +----+           +----+         |
         |provider  provider|          |
         |                  |          |
         |                  |          |
         |customer  customer|  customer|
         +---------------+  |+---------+
           backup service|  ||primary service
                        +----+
                        |AS 1|
                        +----+

+----+ 同輩同輩+----+ |3として|------------------------|4として| +----+ +----+ ||プロバイダープロバイダー| |+----------------+ | | | | |顧客|顧客| +----+ 同輩同輩+----+ | |2として|-----------|5として| | +----+ +----+ | |プロバイダープロバイダー| | | | | | | | |顧客顧客| 顧客| +---------------+ |+---------+ アフターサービス| ||一次業務+----+ |1として| +----+

                                 Figure 3

図3

   In this example, the intended state is that AS2 and AS5 are both
   backup providers to AS1, and AS4 is the primary provider.  When the
   link between AS1 and AS4 breaks and is subsequently restored, AS3
   will continue to direct traffic to AS1 via AS2 or AS5.  In this case,
   a single reset of the link between AS2 and AS1 will not restore the
   original intended BGP state, as the BGP-selected best route to AS1
   will switch to AS5, and AS2 and AS3 will learn a path to AS1 via AS5.

この例では、意図している状態はAS2とAS5がAS1への両方のバックアッププロバイダーであり、AS4が第一のプロバイダーであるということです。 AS1とAS4とのリンクが壊れて、次に返されるとき、AS3は、AS2かAS5を通してAS1に交通整理し続けるでしょう。 この場合、AS2とAS1とのリンクのただ一つのリセットは元の意図しているBGP状態を回復しないでしょう、AS1へのBGPによって選択された最も良いルートがAS5に切り替わって、AS2とAS3がAS5を通して経路をAS1に学ぶとき。

   What AS1 is observing is incoming traffic on the backup link from
   AS2.  Resetting this connection will not restore traffic back to the
   primary path, but instead will switch incoming traffic over to AS5.
   The action required to correct the situation is to simultaneously
   reset both the link to AS2, and also the link to AS5.  This is not
   necessarily an intuitively obvious solution, as at any point on time
   only one of these links will be carrying backup traffic, yet both BGP
   sessions need to be brought down at the same time in order to
   commence restoration of the intended primary and backup state.

AS1がバックアップにおける入って来る交通であることを観測していることはAS2からリンクされます。 この接続をリセットすると、第一の経路への交通後部が回復しませんが、入って来る交通は代わりにAS5に転換されるでしょう。 状況を正すのに必要である動作は同時にAS2へのリンクとAS5へのリンクについても両方をリセットすることです。 これは必ず直観的に明白な解決策であるというわけではありません、しかし、両方のBGPセッションが、これらのリンクの1つだけがバックアップ交通を運ぶ時の任意な点で同時に意図している予備選挙の回復を始めて、状態のバックアップをとるために降ろされる必要があるとき。

Griffin & Huston             Informational                      [Page 6]

RFC 4264                      BGP Wedgies                  November 2005

[6ページ]RFC4264BGP Wedgies2005年11月の情報のグリフィンとヒューストン

5.  BGP and Determinism

5. BGPと決定論

   BGP does not behave deterministically in all cases, and, as a
   consequence, there is intended and unintended non-determinism in BGP.
   For example, the default final tie break in some implementations of
   BGP is to prefer the longest-lived route.  To achieve determinism in
   this last step it would be necessary to use a comparison operator
   that has a predictable outcome, such as a comparison of router
   identifiers.  This class of non-deterministic behavior is termed here
   "intended" non-determinism, in that the policy interactions are, to
   some extent, predictable by network administrators.

BGPはすべての場合で決定論的に振る舞いません、そして、結果として、意図していて故意でない非決定論がBGPにあります。 例えば、BGPのいくつかの実現におけるデフォルトの最終的なタイブレークは最も長く送られたルートを好むことです。 この最後のステップにおける決定論を達成するのに、予測できる結果を持っている比較オペレータを使用するのが必要でしょう、ルータ識別子の比較のように。 非決定論的であるのに「意図し」て、このクラスの非決定論的な振舞いはここに呼ばれます、方針相互作用がネットワーク管理者がある程度予測できるので。

   BGP is also able to generate outcomes that can be described as
   "unintended non-determinism" that can result from unexpected policy
   interactions.  These outcomes do not represent misconfiguration in
   the standard sense, since all policies may look completely rational
   locally, but their interaction across multiple routing entities can
   cause unintended outcomes, and BGP may reach a state that includes
   such unintended outcomes in a non-deterministic manner.

また、BGPは予期していなかった方針相互作用から生じることができる「故意でない非決定論」として記述できる結果を発生させることができます。 複数のルーティング実体の向こう側のそれらの相互作用は故意でない結果を引き起こす場合があります、そして、すべての方針が局所的に完全に合理的に見えるかもしれないので、これらの結果は標準の意味でmisconfigurationを表しませんが、BGPは非決定論的な方法にそのような故意でない結果を含んでいる州に達するかもしれません。

   Unintended non-determinism in BGP would not be as critical an issue
   if all stable routings were guaranteed to be consistent with the
   policy writer's intent.  However, this is not always the case.  The
   above examples indicate that the operation of BGP allows multiple
   stable states to exist from a single configuration state, where some
   of these states are not consistent with the policy writer's intent.
   These particular examples can be described as a form of "route
   pinning", where the route is pinned to a non-preferred path.

すべての安定したroutingsが方針作家の意図と一致しているように保証されるなら、BGPの故意でない非決定論は同じくらい批判的な問題でないでしょうに。 しかしながら、これはいつもそうであるというわけではありません。 上記の例は、複数の安定状態がBGPの操作でただ一つの構成状態から存在するのを示します。(そこでは、これらのいくつかの州が方針作家の意図と一致していません)。 ルートが非都合のよい経路にピンで止められる「ルートのピンで止めること」のフォームとしてこれらの特定の例を記述できます。

   The challenge for the network administrator is to ensure that an
   intended state is maintained.  Under certain circumstances this can
   only be achieved by deliberate service disruption, involving the
   withdrawal of routes being used to forward traffic, and
   re-advertising routes in a certain sequence in order to induce an
   intended BGP state.  However, the knowledge that is required by any
   single network operator administrator in order to understand the
   reason why BGP has stabilized to an unintended state requires BGP
   policy configuration knowledge of remote networks.  In effect, there
   is insufficient local information for any single network
   administrator to correctly identify the root cause of the unintended
   BGP state, nor is there sufficient information to allow any single
   network administrator to undertake a sequence of steps to rectify the
   situation back to the intended routing state.

ネットワーク管理者のための挑戦は意図している状態が維持されるのを保証することです。 ある状況の下では、意図しているBGP状態を引き起こすために交通を進めるのに使用されるルート、および再広告ルートの退出に、ある系列にかかわって、慎重なサービスの崩壊でこれを達成できるだけです。 しかしながら、BGPが故意でない状態に安定していた理由を理解するためにどんな独身のネットワーク・オペレータの管理者によっても必要とされる知識はリモートネットワークに関するBGP方針構成知識を必要とします。 事実上、どんな独身のネットワーク管理者も正しく故意でないBGP状態の根本的原因を特定するように、不十分なローカルの情報があります、そして、どんな独身のネットワーク管理者も意図しているルーティング状態に事態を正常化して戻るためにステップの系列を引き受けるのを許容するために、十分な情報はありません。

   It is reasonable to anticipate that the density of interconnection
   will continue to increase, and the capability for policy-based
   preference settings of learned and re-advertised routes will become
   more expressive.  Therefore, it is reasonable to anticipate that the

インタコネクトの密度が、増加し続けると予期するのが妥当であり、学術的で再広告を出しているルートの方針ベースの好みの設定への能力は、より表現するようになるでしょう。 したがって、それを予期するのは妥当です。

Griffin & Huston             Informational                      [Page 7]

RFC 4264                      BGP Wedgies                  November 2005

[7ページ]RFC4264BGP Wedgies2005年11月の情報のグリフィンとヒューストン

   number of unintended but stable BGP states will increase, and the
   ability to define the necessary sequence of route withdrawals and
   re-advertisements will become more challenging for network operators
   to determine in advance.

故意でない、しかし、安定したBGP州の数は増加するでしょう、そして、ルート退出と再広告の必要な順序を定義する能力はネットワーク・オペレータがあらかじめ決定するように、よりやりがいがあるようになるでしょう。

   Whether this could lead to a BGP routing system reaching a point
   where each network consistently cannot direct traffic in a
   deterministic manner is, at this stage, a matter of speculation.  BGP
   Wedgies illustrate that a sufficiently complex interconnection
   topology, coupled with a sufficiently expressive set of policy
   constructs, can lead to a number of stable BGP states, rather than a
   single intended state.  As the topology complexity increases, it is
   not possible to deterministically predict which state the BGP routing
   system may converge to.  Paradoxically, the demands of inter-domain
   traffic engineering appear to require greater levels of expressive
   capability in policy-based routing directives, operating across
   denser interconnectivity topologies in a deterministic manner.  This
   may not be a sustainable outcome in BGP-based routing systems.

現在のところ、これが各ネットワークが決定論的な方法で一貫して交通整理できないポイントに達するBGPルーティングシステムに通じることができたかどうかが、思惑の問題です。 BGP Wedgiesは、十分表現のセットの方針構造物に結びつけられた十分複雑なインタコネクトトポロジーがただ一つの意図している状態よりむしろ多くの安定したBGP州に通じることができるのを例証します。 トポロジーの複雑さが増加するのに従って、BGPルーティングシステムがどの状態に一点に集まるかもしれないかを決定論的に予測するのは可能ではありません。 逆説的に、相互ドメイン交通工学の要求は方針ベースのルーティング指示における、より大きいレベルの表現の能力を必要とするように見えます、より濃い相互接続性topologiesの向こう側に決定論的な方法で作動して。 これはBGPベースのルーティングシステムの持続可能な結果でないかもしれません。

6.  Security Considerations

6. セキュリティ問題

   BGP is a relaying protocol, where route information is received,
   processed, and forwarded.  BGP contains no specific mechanisms to
   prevent the unauthorized modification of the information by a
   forwarding agent, allowing routing information to be modified or
   deleted, or for false information to be inserted without the
   knowledge of the originator of the routing information or any of the
   recipients.

BGPはリレープロトコルです。(そこでは、経由地案内は、受け取られて、処理されて、転送されます)。 BGPは小口運送業者による情報の権限のない変更を防ぐどんな特定のメカニズムも含んでいません、変更されるか、削除される、または偽情報がルーティング情報の創始者か受取人のどれかに関する知識なしで挿入されるためにルーティングに情報を許容して。

   This memo proposes no modifications to the BGP protocol, nor does it
   propose any changes to the manner of deployment of BGP, and therefore
   introduces no new factors in terms of the security and integrity of
   inter-domain routing.

このメモは、BGPプロトコルへの変更を全く提案しないで、それをします。BGPの展開の方法へのどんな変化も提案して、したがって、相互ドメインルーティングのセキュリティと保全に関してどんな新しい要素も紹介しません。

   This memo illustrates that, in attempting to create policy-based
   outcomes relating to path selection for incoming traffic, it is
   possible to generate BGP configurations where there are multiple
   stable outcomes, rather than a single outcome.  Furthermore, of these
   instances of multiple outcomes, there are cases where the BGP
   selection of a particular outcome is not a deterministic selection.

ただ一つの結果よりむしろ複数の安定した結果があるところでこのメモは、入って来る交通のための経路選択に関連する方針ベースの結果を作成するのを試みるのにおいてBGP構成を発生させるのが可能であることを例証します。 その上、ケースは特定の結果のBGP選択が決定論的な選択でないところの複数の結果のこれらの例のものです。

   This class of behaviour may be exploitable by a hostile third party.
   A common theme of BGP Wedgies is that starting from an intended or
   desired forwarding state, the loss and subsequent restoration of an
   eBGP peering connection can flip the network's forwarding
   configuration into an unintended and potentially undesired state.
   Significant administrative effort, based on BGP state and
   configuration knowledge that may not be locally available, may be

このクラスのふるまいは敵対的な第三者で利用可能であるかもしれません。 BGP Wedgiesの一般的なテーマはeBGPの状態、損失、およびその後の修復が意図しているか必要な推進からじっと見始めて、接続が故意でなくて潜在的に望まれない状態にネットワークの推進構成をはじき出すことができるということです。 局所的に利用可能でないかもしれないBGP状態と構成知識に基づく重要な管理努力はそうです。

Griffin & Huston             Informational                      [Page 8]

RFC 4264                      BGP Wedgies                  November 2005

[8ページ]RFC4264BGP Wedgies2005年11月の情報のグリフィンとヒューストン

   required to shift the BGP forwarding configuration back to the
   intended or desired forwarding state.  If a hostile third party can
   deliberately cause the BGP session to reset, thereby producing the
   initial conditions that lead to an unintended forwarding state, the
   network impacts of the resulting unintended or undesired forwarding
   state may be long-lived, far outliving the temporary interruption of
   connectivity that triggered the condition.  If these impacts,
   including potential issues of increased cost, reduction of available
   bandwidth, increases in overall latency or degradation of service
   reliability, are significant, then disrupting a BGP session could
   represent an attractive attack vector to a hostile party.

意図しているか必要な推進状態にBGP推進構成を移行して戻させるのが必要です。 敵対的な第三者が故意にその結果、リセットするBGPセッション、生産に故意でない推進状態につながる初期条件を引き起こす場合があるなら、結果として起こる故意でないか望まれない推進状態のネットワーク影響は長命であるかもしれません、状態の引き金となった接続性の一時的な中断より遠くに長生きしていて。 コストの上昇の潜在的問題、利用可能な帯域幅、総合的な潜在の増加の減少またはサービスの信頼性の退行を含むこれらの影響が重要であるなら、BGPセッションを中断すると、敵対的なパーティーは魅力的な攻撃ベクトルに思い浮かぶかもしれません。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

   [RFC1771]  Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
              (BGP-4)", RFC 1771, March 1995.

1995年の[RFC1771]RekhterとY.とT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。

7.2.  Informative References

7.2. 有益な参照

   [RFC1997]  Chandrasekeran, R., Traina, P., and T. Li, "BGP
              Communities Attribute", RFC 1997, August 1996.

[RFC1997] ChandrasekeranとR.とTraina、P.とT.李、「BGP共同体属性」、RFC1997、1996年8月。

Authors' Addresses

作者のアドレス

   Tim G. Griffin
   Computer Laboratory
   University of Cambridge

ケンブリッジのティムG.グリフィンコンピュータ研究所大学

   EMail: Timothy.Griffin@cl.cam.ac.uk

メール: Timothy.Griffin@cl.cam.ac.uk

   Geoff Huston
   Asia Pacific Network Information Centre

ジェフ・ヒューストン・アジア・太平洋のネットワークインフォメーション・センター

   EMail: gih@apnic.net

メール: gih@apnic.net

Griffin & Huston             Informational                      [Page 9]

RFC 4264                      BGP Wedgies                  November 2005

[9ページ]RFC4264BGP Wedgies2005年11月の情報のグリフィンとヒューストン

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

   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 currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Griffin & Huston             Informational                     [Page 10]

グリフィンとヒューストンInformationalです。[10ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

- 演算子

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る