[要約] RFC 3509は、OSPFエリアボーダールーターの代替実装に関するガイドラインです。このRFCの目的は、異なるベンダー間でのOSPFエリアボーダールーターの互換性を向上させることです。
Network Working Group A. Zinin
Request for Comments: 3509 Alcatel
Category: Informational A. Lindem
Redback Networks
D. Yeung
Procket Networks
April 2003
Alternative Implementations of OSPF Area Border Routers
OSPFエリアボーダールーターの代替実装
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 (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
Open Shortest Path First (OSPF) is a link-state intra-domain routing protocol used for routing in IP networks. Though the definition of the Area Border Router (ABR) in the OSPF specification does not require a router with multiple attached areas to have a backbone connection, it is actually necessary to provide successful routing to the inter-area and external destinations. If this requirement is not met, all traffic destined for the areas not connected to such an ABR or out of the OSPF domain, is dropped. This document describes alternative ABR behaviors implemented in Cisco and IBM routers.
Open Shortest Path First（OSPF）は、IPネットワークでのルーティングに使用されるリンク状態のドメイン内ルーティングプロトコルです。OSPF仕様のエリアボーダールーター（ABR）の定義では、バックボーン接続を持つ複数の接続エリアを持つルーターを必要としませんが、実際にエリア間および外部の目的地へのルーティングを成功させる必要があります。この要件が満たされていない場合、そのようなABRに接続されていない領域またはOSPFドメインから外れているエリアに運命づけられているすべてのトラフィックが削除されます。このドキュメントでは、シスコおよびIBMルーターに実装された代替ABR動作について説明しています。
1 Overview
1。概要
An OSPF routing domain can be split into several subdomains, called areas, which limit the scope of LSA flooding. According to [Ref1] a router having attachments to multiple areas is called an "area border router" (ABR). The primary function of an ABR is to provide its attached areas with Type-3 and Type-4 LSAs, which are used for describing routes and AS boundary routers (ASBRs) in other areas, as well as to perform actual inter-area routing.
OSPFルーティングドメインは、LSA洪水の範囲を制限する領域と呼ばれるいくつかのサブドメインに分割できます。[Ref1]によると、複数の領域に添付ファイルを持つルーターは、「エリアボーダールーター」（ABR）と呼ばれます。ABRの主な機能は、付着した領域にタイプ3およびタイプ4 LSAを提供することです。これは、他の領域のルートの記述および境界ルーター（ASBR）として使用され、実際のエリア間ルーティングを実行するために使用されます。
In OSPF domains the area topology is restricted so that there must be a backbone area (area 0) and all other areas must have either physical or virtual connections to the backbone. The reason for this star-like topology is that OSPF inter-area routing uses the distance-vector approach and a strict area hierarchy permits avoidance of the "counting to infinity" problem. OSPF prevents inter-area routing loops by implementing a split-horizon mechanism, allowing ABRs to inject into the backbone only Summary-LSAs derived from the intra-area routes, and limiting ABRs' SPF calculation to consider only Summary-LSAs in the backbone area's link-state database.
OSPFドメインでは、バックボーン領域（エリア0）が必要であり、他のすべての領域がバックボーンへの物理的または仮想的な接続を持つ必要があるように、面積トポロジが制限されています。この星のようなトポロジの理由は、OSPF間のエリア間ルーティングが距離ベクトルアプローチを使用しており、厳格な領域階層により「無限へのカウント」問題の回避が許可されているためです。OSPFは、スプリットホリゾンメカニズムを実装し、ABRがエリア内ルートに由来するバックボーンのみの要約LSAに注入することにより、ABRSのSPF計算を制限するバックボーンエリアのSPF計算を制限できるようにすることにより、エリア間ルーピングループを防ぎます。リンク状態データベース。
The last restriction leads to a problem when an ABR has no backbone connection (in OSPF, an ABR does not need to be attached to the backbone). Consider a sample OSPF domain depicted in the Figure 1.
最後の制限は、ABRにバックボーン接続がない場合に問題につながります（OSPFでは、ABRをバックボーンに取り付ける必要はありません）。図1に描かれているサンプルOSPFドメインを考えてみましょう。
. .
. Area 0 .
+--+ +--+
..|R1|.. ..|R2|..
. +--+ .. +--+ .
. .. .
. +--+ .
. Area1 |R3| Area2 .
. +--+ +--+ .
. .. |R4| .
. . . +--+ .
....... .......
Figure 1. ABR dropping transit traffic
図1. ABRドロップトランジットトラフィック
In this example R1, R2, and R3 are ABRs. R1 and R2 have backbone connections, while R3 doesn't.
この例では、R1、R2、およびR3はABRです。R1とR2にはバックボーン接続がありますが、R3は接続していません。
Following the section 12.4.1 of [Ref1], R3 will identify itself as an ABR by setting the bit B in its router-LSA. Being an ABR, R3 can only consider summary-LSAs from the backbone when building the routing table (according to section 16.2 of [Ref1]), so it will not have any inter-area routes in its routing table, but only intra-area routes from both Area 1 and Area 2. Consequently, according to section 12.4.3 of [Ref1], R3 will originate into Areas 1 and 2 only summary-LSAs covering destinations in the directly attached areas, i.e., in Area 2---the summary-LSAs for Area 1, and in Area 1---the summary-LSAs for Area 2.
[Ref1]のセクション12.4.1に続いて、R3はRouter-LSAにビットBを設定することにより、ABRとして自分自身を識別します。ABRであるため、R3はルーティングテーブルを構築するときにバックボーンからの概要LSAのみを検討できます（[Ref1]のセクション16.2に従って）。エリア1とエリア2の両方からのルート。その結果、[Ref1]のセクション12.4.3によると、R3は、直接接続されたエリアの目的地、つまりエリア2の目的地をカバーする概要1および2のみに由来します。エリア1の要約LSA、およびエリア1 ---エリア2の概要LSA。
At the same time, router R2, as an ABR connected to the backbone, will inject into Area 2 summary-LSAs describing the destinations in Area 0 (the backbone), Area 1 and other areas reachable through the backbone.
同時に、バックボーンに接続されたABRとしてRouter R2は、バックボーンから到達可能なエリア0（バックボーン）、エリア1、およびその他のエリアの目的地を説明するエリア2サマリLSAに注入します。
This results in a situation where internal router R4 calculates its routes to destinations in the backbone and areas other than Area 1 via R2. The topology of Area 2 itself can be such that the best path from R4 to R2 is via R3, so all traffic destined for the backbone and backbone-attached areas goes through R3. Router R3 in turn, having only intra-area routes for areas 1 and 2, will drop all traffic not destined for the areas directly attached to it. The same problem can occur when a backbone-connected ABR loses all of its adjacencies in the backbone---even if there are other normally functioning ABRs in the attached areas, all traffic going to the backbone (destined for it or for other areas) will be dropped.
これにより、内部ルーターR4がバックボーンの目的地へのルートとR2を介してエリア1以外のエリアへのルートを計算する状況になります。エリア2自体のトポロジーは、R4からR2への最適なパスがR3を介してであるようにすることができるため、バックボーンおよびバックボーンに適合したエリアに向けたすべてのトラフィックはR3を通過します。Router R3は、エリア1と2のエリア内ルートのみを持つことで、直接接続されたエリアに運命づけられていないすべてのトラフィックをドロップします。バックボーンに接続されたABRがバックボーン内のすべての隣接を失うと同じ問題が発生する可能性があります。ドロップされます。
In a standard OSPF implementation this situation can be remedied by use of Virtual Links (see section 15 of [Ref1] for more details). In this case, router R3 will have a virtual backbone connection, will form an adjacency over it, will receive all LSAs directly from a backbone-attached router (R1 or R2, or both in our example) and will install intra- or inter-area routes.
標準のOSPF実装では、この状況は仮想リンクを使用して改善できます（詳細については、[Ref1]のセクション15を参照）。この場合、Router R3は仮想バックボーン接続を持ち、その上に隣接するものを形成し、バックボーンに取り付けられたルーター（R1またはR2、またはその両方の例）からすべてのLSAを直接受け取り、内部またはInter-Inter-をインストールしますエリアルート。
While being an unavoidable technique for repairing a partitioned backbone area, the use of virtual links in the described situation adds extra configuration headaches and system traffic overhead.
パーティション化されたバックボーン領域を修復するための避けられない手法である一方で、説明された状況で仮想リンクを使用すると、追加の構成ヘッドチャッシュとシステムトラフィックオーバーヘッドが追加されます。
Another situation where standard ABR behavior does not provide acceptable results is when it is necessary to provide redundant connectivity to an ASBR via several different OSPF areas. This would allow a provider to aggregate all their customers connecting through a single access point into one area while still offering a redundant connection through another access point in a different area, as shown in Figure 2.
標準的なABRの動作が許容可能な結果を提供しない別の状況は、いくつかの異なるOSPF領域を介してASBRに冗長接続を提供する必要がある場合です。これにより、プロバイダーは、図2に示すように、1つのアクセスポイントを介して1つの領域に接続するすべての顧客を1つの領域に接続し、別の領域の別のアクセスポイントを介して冗長接続を提供することができます。
. .
. Area 0 .
+--+ +--+
..|R1|.. ..|R2|..
. +--+ .. +--+ .
. .. .
. .. .
. Area1 .. Area2 .
. .. .
. .. .
. +--+ .
.......|R3|.......
ASBR+--+
/..\
--+- -+--
CN1 CNx
Customer Networks (CN1--CNx) Advertised as AS External or NSSA External Routes
外部またはNSSA外部ルートとして宣伝されている顧客ネットワーク（CN1 - CNX）
Figure 2. Dual Homed Customer Router
図2.デュアルホームの顧客ルーター
This technique is already used in a number of networks including one of a major provider.
この手法は、主要なプロバイダーの1つを含む多くのネットワークですでに使用されています。
The next section describes alternative ABR behaviors, implemented in Cisco and IBM routers. The changes are in the ABR definition and inter-area route calculation. Any other parts of standard OSPF are not changed.
次のセクションでは、CiscoおよびIBMルーターに実装されている代替ABRの動作について説明します。変更は、ABR定義およびエリア間ルートの計算にあります。標準のOSPFの他の部分は変更されていません。
These solutions are targeted to the situation when an ABR has no backbone connection. They imply that a router connected to multiple areas without a backbone connection is not an ABR and should function as a router internal to every attached area. This solution emulates a situation where separate OSPF processes are run for each area and supply routes to the routing table. It remedies the situation described in the examples above by not dropping transit traffic. Note that a router following it does not function as a real border router---it doesn't originate summary-LSAs. Nevertheless such a behavior may be desirable in certain situations.
これらのソリューションは、ABRにバックボーン接続がない場合の状況を対象としています。それらは、バックボーン接続のない複数の領域に接続されたルーターがABRではなく、すべての接続領域の内部ルーターとして機能する必要があることを意味します。このソリューションは、各エリアに対して個別のOSPFプロセスが実行され、ルーティングテーブルへの供給ルートが実行される状況をエミュレートします。それは、輸送トラフィックを落とさないことで上記の例で説明されている状況を治療します。それに続くルーターは、実際のボーダールーターとして機能しないことに注意してください---それは概要LSAを発生しないことに注意してください。それにもかかわらず、そのような行動は特定の状況で望ましいかもしれません。
Note that the proposed solutions do not obviate the need of virtual link configuration in case an area has no physical backbone connection at all. The methods described here improve the behavior of a router connecting two or more backbone-attached areas.
提案されたソリューションは、領域が物理的なバックボーン接続がまったくない場合に備えて、仮想リンク構成の必要性を回避しないことに注意してください。ここで説明する方法は、2つ以上のバックボーン接続領域を接続するルーターの動作を改善します。
2 Changes to ABR Behavior
ABRの動作の2の変更
The following definitions will be used in this document to describe the new ABR behaviors:
このドキュメントでは、新しいABRの動作を説明するために次の定義を使用します。
Configured area: An area is considered configured if the router has at least one interface in any state assigned to that area.
構成領域：ルーターにその領域に割り当てられた任意の状態に少なくとも1つのインターフェイスがある場合、エリアは構成されていると見なされます。
Actively Attached area: An area is considered actively attached if the router has at least one interface in that area in the state other than Down.
アクティブに接続されたエリア：ルーターにダウン以外の州のその領域に少なくとも1つのインターフェイスがある場合、エリアはアクティブに接続されていると見なされます。
Active Backbone Connection: A router is considered to have an active backbone connection if the backbone area is actively attached and there is at least one fully adjacent neighbor in it.
アクティブなバックボーン接続：バックボーン領域が積極的に取り付けられており、少なくとも1つの完全に隣接する隣人がいる場合、ルーターはアクティブなバックボーン接続があると見なされます。
Area Border Router (ABR):
エリアボーダールーター（ABR）：
Cisco Systems Interpretation: A router is considered to be an ABR if it has more than one area Actively Attached and one of them is the backbone area.
Cisco Systemsの解釈：複数のエリアがアクティブに接続されており、そのうちの1つがバックボーンエリアがある場合、ルーターはABRと見なされます。
IBM Interpretation: A router is considered to be an ABR if it has more than one Actively Attached area and the backbone area Configured.
IBMの解釈：ルーターは、アクティブに複数の接続された領域があり、バックボーン領域が構成されている場合、ABRと見なされます。
The following changes are made to the base OSPF, described in [Ref1]:
[Ref1]で説明されているベースOSPFには、以下の変更が行われます。
1. The algorithm for Type 1 LSA (router-LSA) origination is changed to prevent a multi-area connected router from identifying itself as an ABR by the bit B (as described in section 12.4.1 of [Ref1]) until it considers itself as an ABR according to the definitions given in section 2.1.
1. タイプ1 LSA（Router-LSA）のオリジネーションのアルゴリズムは、マルチエリア接続ルーターがビットB（[Ref1]のセクション12.4.1で説明されているように）によってABRとしてABRと識別するのを防ぐために変更されます。セクション2.1に記載されている定義に従ってABR。
2. The algorithm for the routing table calculation is changed to allow the router to consider the summary-LSAs from all attached areas if it is not an ABR, but has more than one attached area, or it does not have an Active Backbone Connection. Definitions of the terms used in this paragraph are given in section 2.1.
2. ルーティングテーブル計算のアルゴリズムは、ABRではないが複数の接続領域がある場合、またはアクティブなバックボーン接続がない場合、すべての接続された領域からの要約LSAをルーターが考慮できるように変更されます。この段落で使用される用語の定義は、セクション2.1に記載されています。
So, the paragraph 1 of section 16.2 of [Ref1] should be interpreted as follows:
したがって、[Ref1]のセクション16.2のパラグラフ1は、次のように解釈する必要があります。
"The inter-area routes are calculated by examining summary-LSAs. If the router is an ABR and has an Active Backbone Connection, only backbone summary-LSAs are examined. Otherwise (either the router is not an ABR or it has no Active Backbone Connection), the router should consider summary-LSAs from all Actively Attached areas..."
「エリア間ルートは要約LSAを調べて計算されます。ルーターがABRであり、アクティブなバックボーン接続がある場合、バックボーンの要約LSAのみが調べられます。接続）、ルーターは、アクティブに添付されたすべての領域からの要約LSAを検討する必要があります...」
3. For Cisco ABR approach, the algorithm for the summary-LSAs origination is changed to prevent loops of summary-LSAs in situations where the router considers itself an ABR but doesn't have an Active Backbone Connection (and, consequently, examines summaries from all attached areas). The algorithm is changed to allow an ABR to announce only intra-area routes in such a situation.
3. Cisco ABRアプローチの場合、RouterがABRと見なしているがアクティブなバックボーン接続を持たない状況での要約LSAのループを防ぐために、要約LSASのオリジネーションのアルゴリズムが変更されます（そして、その結果、添付されたすべての要約を調べますエリア）。アルゴリズムは、ABRがこのような状況でエリア内ルートのみを発表できるように変更されます。
So, the paragraph 2 of subsection 12.4.3 of [Ref1] should be interpreted as follows:
したがって、[Ref1]のサブセクション12.4.3のパラグラフ2は次のように解釈する必要があります。
"Summary-LSAs are originated by area border routers. The precise summary routes to advertise into an area are determined by examining the routing table structure (see Section 11) in accordance with the algorithm described below. Note that while only intra-area routes are advertised into the backbone, if the router has an Active Backbone Connection, both intra-area and inter-area routes are advertised into the other areas; otherwise, the router only advertises intra-area routes into non-backbone areas."
「要約LSAはエリアボーダールーターによって発信されます。エリアに広告する正確な要約ルートは、以下のアルゴリズムに従ってルーティングテーブル構造（セクション11を参照）を調べることにより決定されます。ルーターにアクティブなバックボーン接続がある場合、エリア内およびエリア間ルートの両方が他のエリアに宣伝されている場合、ルーターはエリア内ルートを非脳骨領域に宣伝するだけです。」
For this policy to be applied we change steps 6 and 7 in the summary origination algorithm to be as follows:
このポリシーを適用するには、要約オリジネーションアルゴリズムの手順6と7を次のように変更します。
Step 6:
ステップ6：
"Else, if the destination of this route is an AS boundary router, a summary-LSA should be originated if and only if the routing table entry describes the preferred path to the AS boundary router (see Step 3 of Section 16.4). If so, a Type 4 summary-LSA is originated for the destination, with Link State ID equal to the AS boundary router's Router ID and metric equal to the routing table entry's cost. If the ABR performing this algorithm does not have an Active Backbone Connection, it can originate Type 4 summary-LSA only if the type of the route to the ASBR is intra-area. Note: Type 4 summary-LSAs should not be generated if Area A has been configured as a stub area."
「そうでなければ、このルートの宛先が境界ルーターである場合、ルーティングテーブルエントリがAS境界ルーターへの優先パスを記述している場合にのみ、概要LSAを発信する必要があります（セクション16.4のステップ3を参照）。、タイプ4の要約LSAは宛先用に発信され、リンク状態IDは境界ルーターのルーターIDに等しく、メトリックはルーティングテーブルエントリのコストに等しくなります。このアルゴリズムを実行するABRにアクティブなバックボーン接続がない場合、ASBRへのルートのタイプがエリア内である場合にのみ、タイプ4の要約LSAを発信できます。注：領域Aがスタブエリアとして構成されている場合、タイプ4の要約LSAは生成されないでください。」
Step 7:
ステップ7：
"Else, the Destination type is network. If this is an inter-area route and the ABR performing this algorithm has an Active Backbone Connection, generate a Type 3 summary-LSA for the destination, with Link State ID equal to the network's address (if necessary, the Link State ID can also have one or more of the network's host bits set; see Appendix E for details) and metric equal to the routing table cost."
「それ以外の場合、宛先タイプはネットワークです。これがエリア間ルートであり、ABRを実行するABRがアクティブなバックボーン接続を持っている場合、宛先のタイプ3サマリLSAを生成し、リンク状態IDをネットワークのアドレスに等しくします（必要に応じて、リンク状態IDには、1つ以上のネットワークのホストビットが設定されています。詳細については、付録Eを参照してください）とルーティングテーブルコストに等しいメトリックもあります。」
The changes in the ABR behavior described in this section allow a multi-area connected router to successfully route traffic destined for the backbone and other areas. Note that if the router does not have a backbone area Configured it does not actively attract inter-area traffic, because it does not consider itself an ABR and does not originate summary-LSAs. It still can forward traffic from one attached area to another along intra-area routes in case other routers in corresponding areas have the best inter-area paths over it, as described in section 1.2.
このセクションで説明したABRの動作の変更により、マルチエリア接続ルーターは、バックボーンやその他の領域に向けたトラフィックを正常にルーティングできます。ルーターにバックボーン領域が構成されていない場合、ABRとは見なさず、サマリLSAを発生しないため、エリア間のトラフィックを積極的に引き付けることはありません。セクション1.2で説明されているように、対応する領域の他のルーターがその上に最適なエリア間パスを持っている場合、1つの接続されたエリアから別のエリアから別のエリアに沿ってトラフィックを転送できます。
By processing all summaries when the backbone is not active, we prevent the ABR, which has just lost its last backbone adjacency, from dropping any packets going through the ABR in question to another ABR and destined towards the backbone or other areas not connected to the ABR directly.
バックボーンがアクティブでない場合、すべての要約を処理することにより、問題のABRを通過するABRを別のABRに削除し、バックボーンまたはその他の領域に接続されていない他の領域に向かって、ABRを失ったABRを防止します。直接abr。
3 Virtual Link Treatment
3仮想リンク処理
The Cisco ABR approach described in this document requires an ABR to have at least one active interface in the backbone area. This requirement may cause problems with virtual links in those rare situations where the backbone area is purely virtual, as shown in Figure 3, and the state of the VL is determined as in [Ref1].
このドキュメントで説明されているCisco ABRアプローチでは、ABRがバックボーン領域に少なくとも1つのアクティブインターフェイスを持つ必要があります。この要件は、図3に示すように、バックボーン領域が純粋に仮想であり、[Ref1]のようにVLの状態が決定されるまれな状況で仮想リンクに問題を引き起こす可能性があります。
....... ........... ......
. . . .
+--+ VL +--+
|R1|***********|R2|
+--+ +--+
Area 1 . . Area 2 . . Area 3
....... ........... ......
Figure 3. Purely Virtual Backbone
図3.純粋に仮想バックボーン
If R1 and R2 treat virtual links as in [Ref1], their virtual links will never go up, because their router-LSAs do not contain the B-bit, which is, in turn, because the routers do not have active interfaces (virtual links) in the backbone and do not consider themselves ABRs.
R1とR2が仮想リンクを[Ref1]のように処理する場合、ルーターLSAにはBビットが含まれていないため、仮想リンクは決して上がりません。これは、ルーターにアクティブなインターフェイスがないためです（仮想）リンク）バックボーンで、自分自身をABRとは見なさないでください。
Note that this problem does not appear if one of the routers has a real interface in the backbone, as it usually is in real networks.
通常、実際のネットワークにあるため、ルーターの1つがバックボーンに実際のインターフェイスを持っている場合、この問題は表示されないことに注意してください。
Though the situation described is deemed to be rather rare, implementations supporting Cisco ABR behavior may consider changing VL-specific code so that a virtual link is reported up (an InterfaceUp event is generated) when a router with corresponding router-ID is seen via Dijkstra, no matter whether its router-LSA indicates that it is an ABR or not. This means that checking of configured virtual links should be done not in step 4 of the algorithm in 16.1 of [Ref1] when a router routing entry is added, but every time a vertex is added to the SPT in step 3 of the same algorithm.
記載されている状況はかなりまれであると考えられていますが、Cisco ABRの動作をサポートする実装は、VL固有のコードの変更を検討して、対応するRouter-IDを持つルーターがDijkstraを介して見られるときに仮想リンクが報告される（インターフェイスアップイベントが生成される）ことを検討する場合があります。、そのルーター-LSAがABRであるかどうかを示しているかどうかに関係なく。これは、ルータールーティングエントリが追加された場合、同じアルゴリズムのステップ3のSPTに頂点に追加されるたびに、[Ref1]の16.1のアルゴリズムのステップ4では、構成された仮想リンクのチェックを行う必要があることを意味します。
4 Compatibility
4互換性
The changes of the OSPF ABR operations do not influence any aspects of the router-to-router cooperation and do not create routing loops, and hence are fully compatible with standard OSPF. Proof of compatibility is outside the scope of this document.
OSPF ABR操作の変更は、ルーター間協力のどの側面にも影響を及ぼさず、ルーティングループを作成することはないため、標準のOSPFと完全に互換性があります。互換性の証明は、このドキュメントの範囲外です。
5 Deployment Considerations
5つの展開に関する考慮事項
This section discusses the deployments details of the ABR behaviors described in this document. Note that this approach is fully compatible with standard ABR behavior, so ABRs acting as described in [Ref1] and in this document can coexist in an OSPF domain and will function without problems.
このセクションでは、このドキュメントで説明されているABRの動作の展開の詳細について説明します。このアプローチは標準的なABRの動作と完全に互換性があるため、[Ref1]で説明されているABRはOSPFドメインに共存し、問題なく機能する可能性があります。
Deployment of ABRs using the alternative methods improves the behavior of a router connected to multiple areas without a backbone attachment, but can lead to unexpected routing asymmetry, as described below.
代替方法を使用したABRの展開は、バックボーンの付着なしで複数の領域に接続されたルーターの動作を改善しますが、以下で説明するように、予期しないルーティングの非対称性につながる可能性があります。
Consider an OSPF domain depicted in Figure 4.
図4に示すOSPFドメインを考えてみましょう。
. Backbone .
. .
. --------------------- .
. |1 1| .
..+--+.............+--+..
..|R1|..... ....|R4|..
. +--+ . . +--+ .
. 1| . . /4 .
. | 8 +--+ 4 / .
. | +-|R3|---+ .
. 1| / +--+\4 .
. +--+ / . . \ 4 +--+ .
. |R2|/8 . . +--|R5| .
. +--+ . . +--+ .
. | . . | .
. --------- . . -------- .
. net N . . net M .
. . . .
. Area 1 . . Area 2 .
........... ..........
Figure 4. Inter-area routing asymmetry
図4.エリア間ルーティングの非対称性
Assume that R3 uses the approach described in this document. In this case R2 will have inter-area routes to network M via ABR R1 only. R5 in turn will have its inter-area route to network N via R4, but as far as R4 is only reachable via R3, all traffic destined to network N will pass through R3. R3 will have an intra-area route to network N via R2 and will, of course, route it directly to it (because intra-area routes are always preferred over inter-area ones). Traffic going back from network N to network M will pass through R2 and will be routed to R1, as R2 will not have any inter-area routes via R3. So, traffic from N to M will always go through the backbone while traffic from M to N will cross the areas directly via R3 and, in this example, will not use a more optimal path through the backbone.
R3がこのドキュメントで説明されているアプローチを使用していると仮定します。この場合、R2にはABR R1のみを介してネットワークMへのエリア間ルートがあります。R5は、R4を介してネットワークNへのエリア間ルートを備えていますが、R4がR3を介してのみ到達可能である限り、ネットワークNに導くすべてのトラフィックはR3を通過します。R3には、R2を介してネットワークNへのエリア内ルートがあり、もちろん、それを直接ルーティングします（エリア内ルートは常にエリア間のルートよりも常に優先されるためです）。ネットワークNからネットワークMに戻るトラフィックはR2を通過し、R2を介してエリア間ルートがないため、R1にルーティングされます。したがって、NからMへのトラフィックは常にバックボーンを通過しますが、MからNへのトラフィックはR3を介して直接エリアを通過し、この例ではバックボーンを通るより最適なパスを使用しません。
Note that this problem is not caused by the fact that R3 uses the alternative approach. The reason for attracting the attention to it is that R3 is not really functioning as an ABR in case this new behavior is used, i.e., it does not inject summary-LSAs into the attached areas, but inter-area traffic can still go through it.
この問題は、R3が代替アプローチを使用しているという事実によって引き起こされないことに注意してください。それに注意を向ける理由は、この新しい動作が使用された場合にR3がABRとして実際に機能していないこと、つまり、付着した領域に概要LSAを注入するのではなく、エリア間トラフィックがまだそれを通過できることです。。
6 Security Considerations
6つのセキュリティ上の考慮事項
The alternative ABR behaviors specified in this document do not raise any security issues that are not already covered in [Ref1].
このドキュメントで指定されている代替ABRの動作は、[Ref1]でまだカバーされていないセキュリティの問題を提起しません。
7 Acknowledgements
7謝辞
Authors would like to thank Alvaro Retana, Russ White, and Liem Nguyen for their review of the document.
著者は、Alvaro Retana、Russ White、およびLiem Nguyenの文書のレビューに感謝したいと思います。
8 Disclaimer
8免責事項
This document describes OSPF ABR implementations of respective vendors "as is", only for informational purposes, and without any warranties, guarantees or support. These implementations are subject to possible future changes. For the purposes of easier deployment, information about software versions where described behavior was integrated is provided below.
このドキュメントでは、それぞれのベンダーのOSPF ABRの実装については、情報目的でのみ、保証、保証、またはサポートなしでのみ説明しています。これらの実装は、将来の変更の可能性があります。展開を容易にするために、説明された動作が統合されたソフトウェアバージョンに関する情報を以下に示します。
Initial Cisco ABR implementation (slightly different from the one described in this memo, requiring non-backbone areas to be configured, and not necessarily actively attached in the ABR definition) was introduced in Cisco IOS (tm) version 11.1(6). Cisco ABR behavior described in this document was integrated in Cisco IOS (tm) in version 12.1(3)T.
Cisco iOS（TM）バージョン11.1（6）で導入されたのは、初期のCisco ABR実装（このメモで説明されているものとはわずかに異なり、ABR定義に必ずしもアクティブに添付されているわけではありません。このドキュメントで説明されているシスコABRの動作は、バージョン12.1（3）tのCisco iOS（TM）に統合されました。
The ABR behavior described as IBM ABR approach was implemented by IBM in IBM Nways Multiprotocol Routing Services (MRS) 3.3.
IBM ABRアプローチとして説明されているABRの動作は、IBM Nways Multiprotocol Routing Services（MRS）3.3でIBMによって実装されました。
Note that the authors do not intend to keep this document in sync with actual implementations.
著者は、このドキュメントを実際の実装と同期させるつもりはないことに注意してください。
10 References
10の参照
[Ref1] Moy, J., "OSPF version 2", STD 54, RFC 2328, April 1998.
[Ref1] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
11 Authors' Addresses
11著者のアドレス
Alex Zinin Alcatel
アレックス・ジニン・アルカテル
EMail: zinin@psg.com
Derek M. Yeung Procket Networks 1100 Cadillac Ct Milpitas, CA 95035
Derek M. Yeung Procket Networks 1100 Cadillac CT Milpitas、CA 95035
Phone: 408-635-7911 EMail: myeung@procket.com
電話：408-635-7911メール：myeung@procket.com
Acee Lindem Redback Networks 102 Carric Bend Court Cary, NC 27519 USA
ACEE LINDEM REDBACK NETWORKS 102 CARRIC BEND COURT CARY、NC 27519 USA
Phone: 919-387-6971 EMail: acee@redback.com
電話：919-387-6971メール：acee@redback.com
12 Full Copyright Statement
12完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。