RFC4577 日本語訳
4577 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IPVirtual Private Networks (VPNs). E. Rosen, P. Psenak, P.Pillay-Esnault. June 2006. (Format: TXT=61515 bytes) (Updates RFC4364) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Rosen
Request for Comments: 4577 P. Psenak
Updates: 4364 P. Pillay-Esnault
Category: Standards Track Cisco Systems, Inc.
June 2006
コメントを求めるワーキンググループE.ローゼン要求をネットワークでつないでください: 4577のP.Psenakアップデート: 4364年のP.Pillay-Esnaultカテゴリ: 標準化過程シスコシステムズInc.2006年6月
OSPF as the Provider/Customer Edge Protocol for
BGP/MPLS IP Virtual Private Networks (VPNs)
BGP/MPLS IP仮想私設網のためのプロバイダー/顧客縁のプロトコルとしてのOSPF(VPNs)
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
要約
Many Service Providers offer Virtual Private Network (VPN) services to their customers, using a technique in which customer edge routers (CE routers) are routing peers of provider edge routers (PE routers). The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". The base specification for BGP/MPLS IP VPNs presumes that the routing protocol on the interface between a PE router and a CE router is BGP. This document extends that specification by allowing the routing protocol on the PE/CE interface to be the Open Shortest Path First (OSPF) protocol.
多くのService Providersが彼らの顧客に対する兵士のNetwork(VPN)サービスをVirtualに提供します、顧客縁のルータ(CEルータ)がプロバイダー縁のルータ(PEルータ)のルーティング同輩であるテクニックを使用して。 ボーダ・ゲイトウェイ・プロトコル(BGP)はプロバイダーのIP背骨ネットワークの向こう側に顧客のルートを分配するのに使用されます、そして、Multiprotocol Label Switching(MPLS)はプロバイダーの背骨の向こう側にトンネル顧客パケットに使用されます。 これは「BGP/MPLS IP VPN」として知られています。 BGP/MPLS IP VPNsが、ルーティングがPEルータとCEルータとのインタフェースで議定書を作ると推定するので、基礎仕様はBGPです。 PE/CEインタフェースのルーティング・プロトコルがオープンShortest Path First(OSPF)プロトコルであることを許容することによって、このドキュメントはその仕様を広げています。
This document updates RFC 4364.
このドキュメントはRFC4364をアップデートします。
Rosen, et al. Standards Track [Page 1] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................2
2. Specification of Requirements ...................................3
3. Requirements ....................................................4
4. BGP/OSPF Interaction Procedures for PE Routers ..................6
4.1. Overview ...................................................6
4.1.1. VRFs and OSPF Instances .............................6
4.1.2. VRFs and Routes .....................................6
4.1.3. Inter-Area, Intra-Area, and External Routes .........7
4.1.4. PEs and OSPF Area 0 .................................8
4.1.5. Prevention of Loops .................................9
4.2. Details ....................................................9
4.2.1. Independent OSPF Instances in PEs ...................9
4.2.2. Router ID ..........................................10
4.2.3. OSPF Areas .........................................10
4.2.4. OSPF Domain Identifiers ............................10
4.2.5. Loop Prevention ....................................12
4.2.5.1. The DN Bit ................................12
4.2.5.2. Use of OSPF Route Tags ....................12
4.2.5.3. Other Possible Loops ......................13
4.2.6. Handling LSAs from the CE ..........................14
4.2.7. Sham Links .........................................16
4.2.7.1. Intra-Area Routes .........................16
4.2.7.2. Creating Sham Links .......................17
4.2.7.3. OSPF Protocol on Sham Links ...............18
4.2.7.4. Routing and Forwarding on Sham Links ......19
4.2.8. VPN-IPv4 Routes Received via BGP ...................19
4.2.8.1. External Routes ...........................20
4.2.8.2. Summary Routes ............................22
4.2.8.3. NSSA Routes ...............................22
5. IANA Considerations ............................................22
6. Security Considerations ........................................23
7. Acknowledgements ...............................................23
8. Normative References ...........................................23
9. Informative References .........................................24
1. 序論…2 2. 要件の仕様…3 3. 要件…4 4. PEルータのためのBGP/OSPF相互作用手順…6 4.1. 概観…6 4.1.1. VRFsとOSPF例…6 4.1.2. VRFsとルート…6 4.1.3. 相互領域、イントラ領域、および外部のルート…7 4.1.4. PEsとOSPF領域0…8 4.1.5. 輪の防止…9 4.2. 詳細…9 4.2.1. PEsの独立しているOSPF例…9 4.2.2. ルータID…10 4.2.3. OSPF領域…10 4.2.4. OSPFドメイン識別子…10 4.2.5. 防止を輪にしてください…12 4.2.5.1. DNは噛み付きました…12 4.2.5.2. OSPFルートタグの使用…12 4.2.5.3. 他の可能な輪…13 4.2.6. Ceからの取り扱いLSAs…14 4.2.7. リンクを模造してください…16 4.2.7.1. イントラ領域ルート…16 4.2.7.2. 紛い物を作成するのはリンクされます…17 4.2.7.3. OSPFはにせのリンクで議定書を作ります…18 4.2.7.4. 紛い物におけるルート設定と推進はリンクされます…19 4.2.8. BGPを通したVPN-IPv4 Routes Received…19 4.2.8.1. 外部のルート…20 4.2.8.2. 概要ルート…22 4.2.8.3. NSSAルート…22 5. IANA問題…22 6. セキュリティ問題…23 7. 承認…23 8. 標準の参照…23 9. 有益な参照…24
1. Introduction
1. 序論
[VPN] describes a method by which a Service Provider (SP) can use its IP backbone to provide a VPN (Virtual Private Network) service to customers. In that method, a customer's edge devices (CE devices) are connected to the provider's edge routers (PE routers). If the CE device is a router, then the PE router may become a routing peer of the CE router (in some routing protocol) and may, as a result, learn the routes that lead to the CE's site and that need to be distributed to other PE routers that attach to the same VPN.
[VPN]はService Provider(SP)がVPN(仮想の兵士のNetwork)に顧客に対するサービスを供給するのにIP背骨を使用できる方法を説明します。 その方法で、顧客のエッジデバイス(CE装置)はプロバイダーの縁のルータ(PEルータ)に接続されます。 CE装置がルータであるなら、PEルータは、CEルータ(何らかのルーティング・プロトコルの)のルーティング同輩になって、その結果CEのサイトにつながって、同じVPNに付く他のPEルータに分配される必要があるルートを学ぶかもしれません。
Rosen, et al. Standards Track [Page 2] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[2ページ]。
The PE routers that attach to a common VPN use BGP (Border Gateway Protocol) to distribute the VPN's routes to each other. A CE router can then learn the routes to other sites in the VPN by peering with its attached PE router in a routing protocol. CE routers at different sites do not, however, peer with each other.
一般的なVPNに付くPEルータは、VPNのルートを互いに分配するのに、BGP(ボーダ・ゲイトウェイ・プロトコル)を使用します。 CEルータは学ぶことができて、次に、ルーティング・プロトコルのVPNの付属PEルータでじっと見るのによる他のサイトにルートを学んでください。 しかしながら、異なったサイトのCEルータは互いと共にじっと見ません。
It can be expected that many VPNs will use OSPF (Open Shortest Path First) as their IGP (Interior Gateway Protocol), i.e., the routing protocol used by a network for the distribution of internal routes within that network. This does not necessarily mean that the PE routers need to use OSPF to peer with the CE routers. Each site in a VPN can use OSPF as its intra-site routing protocol, while using, for example, BGP [BGP] or RIP (Routing Information Protocol) [RIP] to distribute routes to a PE router. However, it is certainly convenient, when OSPF is being used intra-site, to use it on the PE-CE link as well, and [VPN] explicitly allows this.
多くのVPNsが彼らのIGP(内部のゲートウェイプロトコル)(すなわち、内部のルートの分配にそのネットワークの中でネットワークによって使用されたルーティング・プロトコル)としてOSPF(開いているShortest Path First)を使用すると予想できます。 これは、必ずPEルータが、CEルータでじっと見るのにOSPFを使用する必要を意味するというわけではありません。 VPNの各サイトはPEルータにルートを分配するのに、例えばBGP[BGP]かRIP(ルーティング情報プロトコル)[RIP]を使用している間、イントラサイトルーティング・プロトコルとしてOSPFを使用できます。 しかしながら、確かに、それは便利です、OSPFがまた、PE-CEリンクの上にそれを使用するためには中古のイントラサイトであり、[VPN]が明らかにこれを許容するとき。
Like anything else, the use of OSPF on the PE-CE link has advantages and disadvantages. The disadvantage to using OSPF on the PE-CE link is that it gets the SP's PE router involved, however peripherally, in a VPN site's IGP. The advantages though are:
他の何かのように、PE-CEリンクにおけるOSPFの使用には、利点と損失があります。 PE-CEリンクの上のOSPFを使用することへの不都合はしかしながら、SPのPEルータがそれで周囲にかかわるということです、VPNサイトのIGPで。 もっとも、利点は以下の通りです。
- The administrators of the CE router need not have any expertise
in any routing protocol other than OSPF.
- CEルータの管理者には、OSPF以外のどんなルーティング・プロトコルでも少しの専門的技術もある必要はありません。
- The CE routers do not need to have support for any routing
protocols other than OSPF.
- CEルータはOSPF以外のどんなルーティング・プロトコルのサポートも必要としません。
- If a customer is transitioning his network from a traditional
OSPF backbone to the VPN service described in [VPN], the use of
OSPF on the PE-CE link eases the transitional issues.
- 顧客であるなら、伝統的なOSPF背骨からサービスが[VPN](過渡的が発行するPE-CEリンクの容易さにおけるOSPFの使用)で説明したVPNまで移行は彼のネットワークです。
It seems likely that some SPs and their customers will resolve these trade-offs in favor of the use of OSPF on the PE-CE link. Thus, we need to specify the procedures that must be implemented by a PE router in order to make this possible. (No special procedures are needed in the CE router though; CE routers just run whatever OSPF implementations they may have.)
いくつかのSPsと彼らの顧客はPE-CEリンクにおけるOSPFの使用を支持してこれらのトレードオフを決議しそうでしょう。 したがって、私たちは、これを可能にするようにPEルータで実行しなければならない手順を指定する必要があります。 (もっとも、どんな特別な手順もCEルータで必要ではありません; CEルータはそれらが持っているどんなOSPF実現もただ走らせます。)
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Rosen, et al. Standards Track [Page 3] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[3ページ]。
3. Requirements
3. 要件
Consider a set of VPN sites that are thought of as being in the same "OSPF domain". Two sites are considered to be in the same OSPF domain if it is intended that routes from one site to the other be considered intra-network routes. A set of OSPF sites in the same domain will almost certainly be a set of sites that together constitute an "intranet", each of which runs OSPF as its intra-site routing protocol.
同じ「OSPFドメイン」にあると考えられる1セットのVPNサイトを考えてください。 1つのサイトからもう片方までのルートがイントラネットワークルートであると考えられることを意図するなら、2つのサイトが同じOSPFドメインにあると考えられます。 同じドメインの1セットのOSPFサイトはほぼ確実になるでしょう1セットのそんなに一緒にいるサイトが「イントラネット」を構成するという。こと、それはイントラサイトルーティング・プロトコルとしてOSPFをそれぞれ走らせます。
Per [VPN], the VPN routes are distributed among the PE routers by BGP. If the PE uses OSPF to distribute routes to the CE router, the standard procedures governing BGP/OSPF interactions [OSPFv2] would cause routes from one site to be delivered to another in type 5 LSAs (Link State Advertisements), as "AS-external" routes. This is undesirable; it would be much better to deliver such routes in type 3 LSAs (as inter-area routes), so that they can be distinguished from any "real" AS-external routes that may be circulating in the VPN (that is, so that they can be distinguished by OSPF from routes that really do not come from within the VPN). Hence, it is necessary for the PE routers to implement a modified version of the BGP/OSPF interaction procedures.
[VPN]に従って、VPNルートはPEルータの中でBGPによって分配されます。 PEがCEルータにルートを分配するのにOSPFを使用するなら、BGP/OSPF相互作用[OSPFv2]を治める標準手続きでタイプ5LSAsで、あるサイトからのルートを別のものに届けるでしょう(州Advertisementsをリンクしてください)、「外部」としてのルートとして。 これは望ましくありません。 タイプ3LSAs(相互領域ルートとしての)のそのようなルートを非常に届けるほうがよいでしょう、VPNを循環しているどんな「本当」のAS-外部経路ともそれらを区別できる(すなわち、OSPFが本当にVPNから来ないルートとそれらを区別できるように)ように。 したがって、PEルータがBGP/OSPF相互作用手順の変更されたバージョンを実行するのが必要です。
In fact, we would like to have a very general set of procedures that allows a customer to replace a legacy private OSPF backbone easily with the VPN service. We would like this procedure to meet the following set of requirements:
事実上、私たちは、顧客が容易に遺産の個人的なOSPF背骨をVPNサービスに取り替えることができる非常に一般的なセットの手順が欲しいと思います。 私たちは、この手順に以下のセットの必要条件を満たして欲しいと思います:
- The procedures should not make assumptions about the OSPF
topology. In particular, it should not be assumed that
customer sites are OSPF stub sites or NSSA (Not So Stubby Area)
sites. Nor should it be assumed that a customer site contains
only one OSPF area, or that it has no area 0 routers.
- 手順はOSPFに関する仮定をトポロジーにするべきではありません。 特に、顧客サイトがOSPFスタッブサイトかNSSA(So Stubby Areaでない)サイトであると思うべきではありません。 また、顧客サイトが1つのOSPF領域だけを含んでいるか、またはそれには領域0ルータが全くないのが、想定されるべきではありません。
- If VPN sites A and B are in the same OSPF domain, then routes
from one should be presented to the other as OSPF intra-network
routes. In general, this can be done by presenting such routes
as inter-area routes in type 3 LSAs.
- VPNサイトAとBが同じOSPFドメインにあるなら、1からのルートはOSPFイントラネットワークルートとしてもう片方に提示されるべきです。 一般に、相互領域がタイプ3LSAsで発送するようなルートを提示することによって、これができます。
Note that this allows two VPN sites to be connected via an
"OSPF backdoor link". That is, one can have an OSPF link
between the two sites that is used only when the VPN backbone
is unavailable. (This would not be possible with the ordinary
BGP/OSPF interaction procedures. The ordinary procedures would
present routes via the VPN backbone as AS-external routes, and
these could never be preferred to intra-network routes.) This
may be very useful during a period of transition from a legacy
OSPF backbone to a VPN backbone.
これが、2つのVPNサイトが「OSPFの裏口のリンク」を通してつなげられるのを許容することに注意してください。 すなわち、1つは2つのサイトの間のVPN背骨が入手できないときにだけ使用されたOSPFリンクを持つことができます。 (これは普通のBGP/OSPF相互作用手順で可能でないでしょう。 普通の手順がAS-外部経路としてのVPN背骨でルートを提示して、イントラネットワークルートよりこれらは決して好むことができませんでした。) これは遺産OSPF背骨からVPN背骨までの過渡期の間、非常に役に立つかもしれません。
Rosen, et al. Standards Track [Page 4] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[4ページ]。
- It should be possible to make use of an "OSPF backdoor link"
between two sites, even if the two sites are in the same OSPF
area and neither of the routers attached to the inter-site
backdoor link is an area 0 router. This can also be very
useful during a transition period, and it eliminates any need
to reconfigure the sites' routers to be ABRs (Area Border
Routers).
- 2つのサイトの間の「OSPFの裏口のリンク」を利用するのは可能であるべきです、2つのサイトが同じOSPF領域にあり、相互サイトの裏口のリンクに付けられたルータのどちらも領域0ルータでなくても。 また、これも過渡期の間、非常に役に立つ場合があります、そして、それはサイトのルータがABRs(領域Border Routers)であることを再構成するどんな必要性も排除します。
Assuming that it is desired to have the route via the VPN
backbone be preferred to the backdoor route, the VPN backbone
itself must be presented to the CE routers at each site as a
link between the two PE routers to which the CE routers are
respectively attached.
裏口のルートよりVPN背骨を通したルートを好ませるのが必要であると仮定する場合、CEルータがそれぞれ付けられている2つのPEルータの間のリンクとして各サイトのCEルータにVPN背骨自体を提示しなければなりません。
- CE routers, connected to PE routers of the VPN service, may
themselves function as OSPF backbone (area 0) routers. An OSPF
backbone may even consist of several "segments" that are
interconnected themselves only via the VPN service. In such a
scenario, full intercommunication between sites connected to
different segments of the OSPF backbone should still be
possible.
- VPNサービスのPEルータに関連づけられたCEルータがそうするかもしれない、自分たち、OSPF背骨(領域0)ルータとしての機能。 OSPF背骨は単にVPNサービスで自分たちでインタコネクトされる数個の「セグメント」から成りさえするかもしれません。 そのようなシナリオでは、OSPF背骨の異なったセグメントにつなげられたサイトの間の完全な相互通信はまだ可能であるべきです。
- The transition from the legacy private OSPF backbone to the VPN
service must be simple and straightforward. The transition is
likely to be phased, such that customer sites are migrated one
by one from the legacy private OSPF backbone to the VPN
service. During the transition, any given site might be
connected to the VPN service, to the legacy OSPF backbone, or
to both. Complete connectivity among all such sites must be
maintained.
- 遺産の個人的なOSPF背骨からVPNサービスまでの変遷は、簡単であって、簡単であるに違いありません。 変遷が位相を合わせられそうである、顧客サイトがあるようなものはひとつずつ遺産の個人的なOSPF背骨からVPNサービスまで移動しました。 変遷の間、どんな与えられたサイトもVPNサービス、または、遺産OSPF背骨、または、両方につなげられるかもしれません。 そのようなすべてのサイトの中の完全な接続性を維持しなければなりません。
Since the VPN service is to replace the legacy backbone, it
must be possible, by suitable adjustment of the OSPF metrics,
to make OSPF prefer routes that traverse the SP's VPN backbone
to alternative routes that do not.
VPNサービスが遺産背骨を取り替えることであるので、OSPFにSPのVPN背骨をそうしない代替のルートに横断するルートを好ませるように、それはOSPF測定基準の適当な調整で可能でなければなりません。
- The OSPF metric assigned to a given route should be carried
transparently over the VPN backbone.
- OSPFメートル法、与えられたルートに割り当てられて、透明にVPN背骨の上まで運ばれるべきです。
Routes from sites that are not in the same OSPF domain will appear as AS-external routes.
同じOSPFドメインにないサイトからのルートはAS-外部経路として現れるでしょう。
We presuppose familiarity with the contents of [OSPFv2], including the OSPF LSA types, and will refer without further exegesis to type 1, 2, 3, etc. LSAs. Familiarity with [VPN] is also presupposed.
私たちは、OSPF LSAタイプを含む[OSPFv2]のコンテンツで親しみを予想して、1、2、3などをタイプするのにさらなる解釈なしで参照するつもりです。 LSAs。 また、[VPN]への親しみは予想されます。
Rosen, et al. Standards Track [Page 5] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[5ページ]。
4. BGP/OSPF Interaction Procedures for PE Routers
4. PEルータのためのBGP/OSPF相互作用手順
4.1. Overview
4.1. 概観
4.1.1. VRFs and OSPF Instances
4.1.1. VRFsとOSPF例
A PE router that attaches to more than one OSPF domain MUST run an independent instance of OSPF for each domain. If the PE is running OSPF as its IGP (Interior Gateway Protocol), the instance of OSPF running as the IGP must be separate and independent from any other instance of OSPF that the PE is running. (Whether these instances are realized as separate processes or merely as separate contexts of a common process is an implementation matter.) Each interface that attaches to a VPN site belongs to no more than one OSPF instance.
1つ以上のOSPFドメインに付くPEルータはOSPFの独立している例を各ドメインへ走らせなければなりません。 PEがIGP(内部のゲートウェイプロトコル)としてOSPFを走らせているなら、IGPとして走るOSPFの例は、PEが走らせているOSPFのいかなる他の例からも別々であって、独立しているに違いありません。 (これらの例が別々の状態で実現されるかどうかが、処理するか、単に一般的な過程の別々の関係として実現問題です。) VPNサイトに付く各インタフェースは1つ未満のOSPF例に属します。
[VPN] defines the notion of a Per-Site Routing and Forwarding Table, or VRF. Each VRF is associated with a set of interfaces. If a VRF is associated with a particular interface, and that interface belongs to a particular OSPF instance, then that OSPF instance is said to be associated with the VRF. If two interfaces belong to the same OSPF instance, then both interfaces must be associated with the same VRF.
[VPN]はPer-サイトルート設定とForwarding Tableか、VRFの概念を定義します。 それぞれのVRFは1セットのインタフェースに関連しています。 VRFが特定のインタフェースに関連していて、そのインタフェースが特定のOSPF例に属すなら、そのOSPF例はVRFに関連していると言われます。 2つのインタフェースが同じOSPF例に属すなら、両方のインタフェースは同じVRFに関連しているに違いありません。
If an interface attaches a PE to a CE, and that interface is associated with a VRF, we will speak of the CE as being associated with the VRF.
インタフェースがPEをCEに取り付けて、そのインタフェースがVRFに関連しているなら、私たちはVRFに関連しているとしてCEについて話すつもりです。
4.1.2. VRFs and Routes
4.1.2. VRFsとルート
OSPF is used to distribute routes from a CE to a PE. The standard OSPF decision process is used to install the best OSPF-distributed routes in the VRF.
OSPFは、CEからPEまでルートを分配するのに使用されます。 標準のOSPF決定の過程は、最も良いOSPFによって分配されたルートをVRFにインストールするのに使用されます。
Per [VPN], BGP is used to distribute VPN-IPv4 routes among PE routers. An OSPF route installed in a VRF may be "exported" by being redistributed into BGP as a VPN-IPv4 route. It may then be distributed by BGP to other PEs. At the other PEs, a VPN-IPv4 route may be "imported" by a VRF and may then be redistributed into one or more of the OSPF instances associated with that VRF.
[VPN]に従って、BGPは、PEルータにVPN-IPv4ルートを分配するのに使用されます。 VRFにインストールされたOSPFルートは、VPN-IPv4ルートとしてBGPに再配付することによって、「輸出されるかもしれません」。 そして、それはBGPによって他のPEsに分配されるかもしれません。 他のPEsでは、VRFはVPN-IPv4ルートを「輸入するかもしれません」、そして、次に、そのVRFに関連しているOSPF例の1つ以上に再配付するかもしれません。
Import from and export to particular VRFs is controlled by the use of the Route Target Extended Communities attribute (or, more simply, Route Target or RT), as specified in [VPN].
特定のVRFsへの輸入と輸出はRoute Target Extended Communities属性(より単にRoute TargetかRT)の使用で制御されます、[VPN]で指定されるように。
A VPN-IPv4 route is "eligible for import" into a particular VRF if its Route Target is identical to one of the VRF's import Route Targets. The standard BGP decision process is used to select, from among the routes eligible for import, the set of VPN-IPv4 routes to be "installed" in the VRF.
Route TargetがVRFの輸入Route Targetsの1つと同じであるなら、VPN-IPv4ルートは特定のVRFに「輸入において、適任です」。 標準のBGP決定の過程は、輸入に、適任のルートからVPN-IPv4ルートのセットがVRFに「インストールされること」を選択するのに使用されます。
Rosen, et al. Standards Track [Page 6] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[6ページ]。
If a VRF contains both an OSPF-distributed route and a VPN-IPv4 route for the same IPv4 prefix, then the OSPF-distributed route is preferred. In general, this means that forwarding is done according to the OSPF route. The one exception to this rule has to do with the "sham link". If the next hop interface for an installed (OSPF- distributed) route is the sham link, forwarding is done according to a corresponding BGP route. This is detailed in Section 4.2.7.4.
VRFがOSPFによって分配されたルートと同じIPv4接頭語のためのVPN-IPv4ルートの両方を含んでいるなら、OSPFによって分配されたルートは好まれます。 一般に、これは、OSPFルートによると、推進することを意味します。 この規則への1つの例外が「にせのリンク」と関係があります。 インストールされた(分配されたOSPF)ルートへの次のホップインタフェースがにせのリンクであるなら、対応するBGPルートによると、推進します。 これはセクション4.2.7で.4に詳細です。
To meet the requirements of Section 3, a PE that installs a particular route into a particular VRF needs to know whether that route was originally an OSPF route and, if so, whether the OSPF instance from which it was redistributed into BGP is in the same domain as the OSPF instances into which the route may be redistributed. Therefore, a domain identifier is encoded as a BGP Extended Communities attribute [EXTCOMM] and distributed by BGP along with the VPN-IPv4 route. The route's OSPF metric and OSPF route type are also carried as BGP attributes of the route.
セクション3に関する必要条件を満たすために、特定のルートを特定のVRFにインストールするPEは、元々、そのルートがOSPFルートであったかどうかと、そうだとすれば、それがBGPに再配付されたOSPF例がルートが再配付されるかもしれないOSPF例と同じドメインにあるかを知る必要があります。 したがって、ドメイン識別子は、BGP Extended Communitiesが[EXTCOMM]を結果と考えるのでコード化されて、VPN-IPv4ルートに伴うBGPによって分配されます。 ルートはOSPFメートル法です、そして、また、OSPFルートタイプはルートのBGP属性として運ばれます。
4.1.3. Inter-Area, Intra-Area, and External Routes
4.1.3. 相互領域、イントラ領域、および外部経路
If a PE installs a particular VPN-IPv4 route (learned via BGP) in a VRF, and if this is the preferred BGP route for the corresponding IPv4 prefix, the corresponding IPv4 route is then "eligible for redistribution" into each OSPF instance that is associated with the VRF. As a result, it may be advertised to each CE in an LSA.
そして、PEが特定のVPN-IPv4ルート(BGPを通して、学習される)をVRFにインストールして、これが対応するIPv4接頭語のための都合のよいBGPルートであるなら、対応するIPv4ルートはそれぞれのVRFに関連しているOSPF例に「再分配において、適任です」。 その結果、LSAの各CEにそれの広告を出すかもしれません。
Whether a route that is eligible for redistribution into OSPF is actually redistributed into a particular OSPF instance may depend upon the configuration. For instance, the PE may be configured to distribute only the default route into a given OSPF instance. In this case, the routes that are eligible for redistribution would not actually be redistributed.
実際に再分配に、OSPFに適任のルートを特定のOSPF例に再配付するかどうかが構成に依存するかもしれません。 例えば、PEは、与えられたOSPF例にデフォルトルートだけを分配するために構成されるかもしれません。 この場合、再分配に、適任のルートは実際に再配付されないでしょう。
In the following, we discuss the procedures for redistributing a BGP-distributed VPN-IPv4 route into OSPF; these are the procedures to be followed whenever such a route is eligible to be redistributed into OSPF and the configuration does not prevent such redistribution.
以下では、私たちはBGPによって分配されたVPN-IPv4ルートをOSPFに再配付するための手順について議論します。 これらはそのようなルートがOSPFに再配付される資格があるときはいつも、続くべき手順です、そして、構成はそのような再分配を防ぎません。
If the route is from an OSPF domain different from that of the OSPF instance into which it is being redistributed, or if the route is not from an OSPF domain at all, then the route is considered an external route.
ルートがそれが再配付されているOSPF例のものと異なったOSPFドメインから来ているか、またはルートが全くOSPFドメインから来ていないなら、ルートは外部経路であると考えられます。
If the route is from the same OSPF domain as the OSPF instance into which it is being redistributed, and if it was originally advertised to a PE as an OSPF external route or an OSPF NSSA route, it will be treated as an external route. Following the normal OSPF procedures, external routes may be advertised to the CE in type 5 LSAs, or in
ルートがそれが再配付されているOSPF例と同じOSPFドメインから来ていて、元々OSPF外部経路かOSPF NSSAルートとしてPEに広告に掲載されたなら、それは外部経路として扱われるでしょう。 正常なOSPF手順に従って、タイプ5LSAsか中にCEに外部経路の広告を出すかもしれません。
Rosen, et al. Standards Track [Page 7] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[7ページ]。
type 7 LSAs, or not at all, depending on the type of area to which the PE/CE link belongs.
とんでもない、7LSAsをタイプしてください、またはPE/CEリンクが属する領域のタイプに頼ること。
If the route is from the same OSPF domain as the OSPF instance into which it is being redistributed, and if it was originally advertised to a PE as an inter-area or intra-area route, the route will generally be advertised to the CE as an inter-area route (in a type 3 LSA).
ルートがそれが再配付されているOSPF例と同じOSPFドメインから来ていて、元々相互領域かイントラ領域ルートとしてそれをPEに広告に掲載したなら、一般に、相互領域ルート(タイプ3LSAでの)としてCEにルートの広告を出すでしょう。
As a special case, suppose that PE1 attaches to CE1, and that PE2 attaches to CE2, where:
特殊なものとして、PE1がCE1に付いて、PE2がCE2、どこに付くかと仮定してください:
- the OSPF instance containing the PE1-CE1 link and the OSPF
instance containing the PE2-CE2 link are in the same OSPF
domain, and
- そしてPE1-CE1リンクを含むOSPF例とPE2-CE2リンクを含むOSPF例が同じOSPFドメインにある。
- the PE1-CE1 and PE2-CE2 links are in the same OSPF area A (as
determined by the configured OSPF area number),
- PE1-CE1とPE2-CE2リンクが同じOSPF領域Aにあります(構成されたOSPF区域番号で決定するように)。
then, PE1 may flood to CE1 a type 1 LSA advertising a link to PE2, and PE2 may flood to CE2 a type 1 LSA advertising a link to PE1. The link advertised in these LSAs is known as a "sham link", and it is advertised as a link in area A. This makes it look to routers within area A as if the path from CE1 to PE1 across the service provider's network to PE2 to CE2 is an intra-area path. Sham links are an OPTIONAL feature of this specification and are used only when it is necessary to have the service provider's network treated as an intra-area link. See Section 4.2.7 for further details about the sham link.
次に、PE1はPE2へのリンクの広告を出すタイプ1LSAをCE1へあふれさせるかもしれません、そして、PE2はPE1へのリンクの広告を出すタイプ1LSAをCE2へあふれさせるかもしれません。 「にせのリンク」としてこれらのLSAsの広告に掲載されたリンクを知っています、そして、まるでCE2へのPE2へのサービスプロバイダーのネットワークの向こう側のCE1からPE1までの経路がイントラ領域経路であるかのように領域Aの中で領域A.Thisのリンクでルータを当てにするとき、それの広告を出します。 にせのリンクは、この仕様のOPTIONALの特徴であり、イントラ領域のリンクとしてサービスプロバイダーのネットワークを扱わせるのが必要であるときにだけ、使用されています。 さらに詳しい明細については紛い物に関するセクション4.2.7がリンクされるのを見てください。
The precise details by which a PE determines the type of LSA used to advertise a particular route to a CE are specified in Section 4.2.8. Note that if the VRF is associated with multiple OSPF instances, the type of LSA used to advertise the route might be different in different instances.
PEが、LSAのタイプが以前はよく特定のルートのCEに広告を出していたことを決定する正確な詳細はセクション4.2.8で指定されます。 VRFが複数のOSPF例に関連しているなら、ルートの広告を出すのに使用されるLSAのタイプが異なった例において異なるかもしれないことに注意してください。
Note that if a VRF is associated with several OSPF instances, a given route may be redistributed into some or all of those OSPF instances, depending on the characteristics of each instance. If redistributed into two or more OSPF instances, it may be advertised within each instance using a different type of LSA, again depending on the characteristics of each instance.
VRFがいくつかのOSPF例に関連しているなら、与えられたルートがそれらのOSPF例のいくつかかすべてに再配付されるかもしれないことに注意してください、それぞれの例の特性によって。 2つ以上のOSPF例に再配付するなら、各例の中にLSAの異なったタイプを使用することでそれの広告を出すかもしれません、再びそれぞれの例の特性によって。
4.1.4. PEs and OSPF Area 0
4.1.4. PEsとOSPF領域0
Within a given OSPF domain, a PE may attach to multiple CEs. Each PE/CE link is assigned (by configuration) to an OSPF area. Any link can be assigned to any area, including area 0.
与えられたOSPFドメインの中では、PEは複数のCEsに付くかもしれません。 それぞれのPE/CEリンクはOSPF領域に割り当てられます(構成で)。 領域0を含むどんな領域にもどんなリンクも割り当てることができます。
Rosen, et al. Standards Track [Page 8] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[8ページ]。
If a PE attaches to a CE via a link that is in a non-zero area, then the PE serves as an ABR for that area.
PEが非ゼロ領域にあるリンクを通してCEに付くなら、PEはその領域へのABRとして機能します。
PEs can thus be considered OSPF "area 0 routers", i.e., they can be considered part of the "OSPF backbone". Thus, they are allowed to distribute inter-area routes to the CE via Type 3 LSAs.
その結果、OSPF「領域0ルータ」であるとPEsを考えることができます、すなわち、「OSPF背骨」の一部であるとそれらを考えることができます。 したがって、彼らはType3LSAsを通して相互領域ルートをCEに分配できます。
If the OSPF domain has any area 0 routers other than the PE routers, then at least one of those MUST be a CE router and MUST have an area 0 link to at least one PE router. This adjacency MAY be via an OSPF virtual link. (The ability to use an OSPF virtual link in this way is an OPTIONAL feature.) This is necessary to ensure that inter-area routes and AS-external routes can be leaked between the PE routers and the non-PE OSPF backbone.
OSPFドメインに何かPEルータ以外の領域0ルータがあるなら、少なくともそれらの1つで、CEルータでなければならなく、領域0は少なくとも1つのPEルータにリンクされなければなりません。 OSPFの仮想のリンクを通してこの隣接番組はあるかもしれません。 (このようにOSPFの仮想のリンクを使用する能力はOPTIONALの特徴です。) これが、PEルータと非PE OSPF背骨の間で相互領域ルートとAS-外部経路を漏らすことができるのを保証するのに必要です。
Two sites that are not in the same OSPF area will see the VPN backbone as being an integral part of the OSPF backbone. However, if there are area 0 routers that are NOT PE routers, then the VPN backbone actually functions as a sort of higher-level backbone, providing a third level of hierarchy above area 0. This allows a legacy OSPF backbone to become disconnected during a transition period, as long as the various segments all attach to the VPN backbone.
同じOSPF領域にない2つのサイトがOSPF背骨の不可欠の部分であるとVPN背骨をみなすでしょう。 しかしながら、NOT PEルータである領域0ルータがあれば、VPN背骨は実際に一種の、よりハイレベルの背骨として機能します、第3のレベルの階層構造を領域0の上に提供して。 これで、遺産OSPF背骨は過渡期の間、外されるようになることができます、様々なセグメントがVPN背骨にすべて付く限り。
4.1.5. Prevention of Loops
4.1.5. 輪の防止
If a route sent from a PE router to a CE router could then be received by another PE router from one of its own CE routers, it would be possible for routing loops to occur. To prevent this, a PE sets the DN bit [OSPF-DN] in any LSA that it sends to a CE, and a PE ignores any LSA received from a CE that already has the DN bit sent. Older implementations may use an OSPF Route Tag instead of the DN bit, in some cases. See Sections 4.2.5.1 and 4.2.5.2.
次に、別のPEルータでそれ自身のCEルータの1つからPEルータからCEルータに送られたルートを受け取ることができるなら、ルーティング輪が現れるのは、可能でしょうに。 これを防ぐために、PEはそれがCEに送るどんなLSAにもDNビット[OSPF-DN]をはめ込みます、そして、PEはDNビットを既に送らせるCEから受け取られたどんなLSAも無視します。 より古い実現はいくつかの場合にDNビットの代わりにOSPF Route Tagを使用するかもしれません。 そして、セクション4.2.5を見てください、.1、4.2 .5 .2。
4.2. Details
4.2. 詳細
4.2.1. Independent OSPF Instances in PEs
4.2.1. PEsの独立しているOSPF例
The PE MUST support one OSPF instance for each OSPF domain to which it attaches. These OSPF instances function independently and do not leak routes to each other. Each instance of OSPF MUST be associated with a single VRF. If n CEs associated with that VRF are running OSPF on their respective PE/CE links, then those n CEs are OSPF adjacencies of the PE in the corresponding instance of OSPF.
PE MUSTはそれが付くそれぞれのOSPFドメインあたり1つのOSPF例を支持します。 これらのOSPF例は、独自に機能して、ルートを互いに漏らしません。 各例、OSPF MUSTでは、独身のVRFに関連してください。 そのVRFに関連しているn CEsが彼らのそれぞれのPE/CEリンクの上のOSPFを走らせているなら、それらのn CEsがOSPFの対応する例で、PEのOSPF隣接番組です。
Generally, though not necessarily, if the PE attaches to several CEs in the same OSPF domain, it will associate the interfaces to those PEs with a single VRF.
一般に、必ずはありませんが、PEが同じOSPFドメインの数個のCEsに付くなら、それは独身のVRFと共にそれらのPEsにインタフェースを関連づけるでしょう。
Rosen, et al. Standards Track [Page 9] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[9ページ]。
4.2.2. Router ID
4.2.2. ルータID
If a PE and a CE are communicating via OSPF, the PE will have an OSPF Router ID that is valid (i.e., unique) within the OSPF domain. More precisely, each OSPF instance has a Router ID. Different OSPF instances may have different Router IDs.
PEとCEがOSPFを通って交信する予定であると、PEには、OSPFドメインの中で有効な(すなわち、ユニークな)OSPF Router IDがあるでしょう。 より正確に、それぞれのOSPF例には、Router IDがあります。 異なったOSPF例には、異なったRouter IDがあるかもしれません。
4.2.3. OSPF Areas
4.2.3. OSPF領域
A PE-CE link may be in any area, including area 0; this is a matter of the OSPF configuration.
PE-CEリンクが領域0を含むどんな領域にもあるかもしれません。 これはOSPF構成の問題です。
If a PE has a link that belongs to a non-zero area, the PE functions as an Area Border Router (ABR) for that area.
PEに非ゼロ領域に属すリンクがあるなら、PEはその領域へのArea Border Router(ABR)として機能します。
PEs do not pass along the link state topology from one site to another (except in the case where a sham link is used; see Section 4.2.7).
PEsは1つのサイトから別のサイトまでリンク州のトポロジーを回しません(ケース以外に中にせのリンクが使用されている; セクション4.2.7を見てください)。
Per [OSPFv2, Section 3.1], "the OSPF backbone always contains all area border routers". The PE routers are therefore considered area 0 routers. Section 3.1 of [OSPFv2] also requires that area 0 be contiguous. It follows that if the OSPF domain has any area 0 routers other than the PE routers, at least one of those MUST be a CE router, and it MUST have an area 0 link (possibly a virtual link) to at least one PE router.
[OSPFv2、セクション3.1]あたり「OSPF背骨はいつもすべての境界ルータを含んでいます」。 したがって、PEルータは領域0ルータであると考えられます。 また、[OSPFv2]のセクション3.1は、領域0が隣接であることを必要とします。 OSPFドメインに何かPEルータ以外の0つのルータ、少なくともそれらの1つの領域があるならそれがCEルータであるに違いなく、領域0がそれによって少なくとも1つのPEルータにリンクされなければならない(ことによると仮想のリンク)ということになります。
4.2.4. OSPF Domain Identifiers
4.2.4. OSPFドメイン識別子
Each OSPF instance MUST be associated with one or more Domain Identifiers. This MUST be configurable, and the default value (if none is configured) SHOULD be NULL.
それぞれのOSPF例は1Domain Identifiersに関連しているに違いありません。 これは、構成可能であって、デフォルト値(なにも構成されないなら)SHOULDであるに違いありません。NULLになってください。
If an OSPF instance has multiple Domain Identifiers, one of these is considered its "primary" Domain Identifier; this MUST be determinable by configuration. If an OSPF instance has exactly one Domain Identifier, this is of course its primary Domain Identifier. If an OSPF instance has more than one Domain Identifier, the NULL Domain Identifier MUST NOT be one of them.
OSPF例に複数のDomain Identifiersがあるなら、これらの1つは「第一」のDomain Identifierであると考えられます。 これは構成で決定できるに違いありません。 OSPF例にちょうど1Domain Identifierがあるなら、これはもちろん第一のDomain Identifierです。 OSPF例に1Domain Identifierがあるなら、NULL Domain Identifierは彼らのひとりであるはずがありません。
If a route is installed in a VRF by a particular OSPF instance, the primary Domain Identifier of that OSPF instance is considered the route's Domain Identifier.
ルートが特定のOSPF例によってVRFにインストールされるなら、そのOSPF例の第一のDomain IdentifierはルートのDomain Identifierであると考えられます。
Consider a route, R, that is installed in a VRF by OSPF instance I1, then redistributed into BGP as a VPN-IPv4 route, and then installed by BGP in another VRF. If R needs to be redistributed into OSPF instance I2, associated with the latter VRF, the way in which R is
ルート、OSPF例のI1によってVRFにインストールされて、次に、VPN-IPv4ルートとしてBGPに再配付されて、次にBGPによって別のVRFにインストールされるRを考えてください。 Rが、再配付される必要があるなら、後者のVRF、入口に関連づけられたOSPF例のI2にはどのRがありますか?
Rosen, et al. Standards Track [Page 10] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[10ページ]。
advertised in I2 will depend upon whether R's Domain Identifier is one of I2's Domain Identifiers. If R's Domain Identifier is not one of I2's Domain Identifiers, then, if R is redistributed into I2, R will be advertised as an AS-external route, no matter what its OSPF route type is. If, on the other hand, R's Domain Identifier is one of I2's Domain Identifiers, how R is advertised will depend upon R's OSPF route type.
I2の広告に掲載されていて、RのDomain IdentifierがI2のDomain Identifiersのひとりであるかどうかによるでしょう。 RをI2に再配付して、RのDomain IdentifierがI2のDomain Identifiersのひとりでないなら、次に、AS-外部経路としてRの広告を出すでしょう、OSPFルートタイプが者であっても。 他方では、RのDomain IdentifierがI2のDomain Identifiersのひとりであるなら、どうRの広告を出すかはRのOSPFルートタイプに頼るでしょう。
If two OSPF instances are in the same OSPF domain, then either:
次に、2つのOSPF例が同じOSPFドメインにあるなら:
1. They both have the NULL Domain Identifier, OR
1. それらの両方には、NULL Domain Identifier、ORがあります。
2. Each OSPF instance has the primary Domain Identifier of the
other as one of its own Domain Identifiers.
2. それぞれのOSPF例には、それ自身のDomain Identifiersの1つとしてもう片方の第一のDomain Identifierがあります。
If two OSPF instances are in different OSPF domains, then either:
次に、2つのOSPF例が異なったOSPFドメインにあるなら:
3. They both have the NULL Domain Identifier, OR
3. それらの両方には、NULL Domain Identifier、ORがあります。
4. Neither OSPF instance has the Primary Domain Identifier of the
other as one of its own Domain Identifiers.
4. どちらのOSPF例も、それ自身のDomain Identifiersの1つとしてもう片方のPrimary Domain Identifierがありません。
(Note that if two OSPF instances each have the NULL Domain Identifier, we cannot tell from the Domain Identifier whether they are in the same OSPF Domain. If they are in different domains, and if routes from one are distributed into the other, the routes will appear as intra-network routes, which may not be what is intended.)
(それぞれ2つのOSPF例にNULL Domain Identifierがあるなら、私たちが、Domain Identifierからそれらが同じOSPF Domainにあるかわからないことに注意してください。 彼らが異なったドメインにいて、1からのルートがもう片方に分配されると、ルートはイントラネットワークルートとして現れるでしょう。(ルートは意図することでないかもしれません)。)
A Domain Identifier is an eight-byte quantity that is a valid BGP Extended Communities attribute, as specified in Section 4.2.4. If a particular OSPF instance has a non-NULL Domain Identifier, when routes from that OSPF instance are distributed by BGP as VPN-IPv4 routes, the routes MUST carry the Domain Identifier Extended Communities attribute that corresponds to the OSPF instance's Primary Domain Identifier. If the OSPF instance's Domain Identifier is NULL, the Domain Identifier Extended Communities attribute MAY be omitted when routes from that OSPF instance are distributed by BGP; alternatively, a value of the Domain Identifier Extended Communities attribute that represents NULL (see Section 4.2.4) MAY be carried with the route.
Domain Identifierはセクション4.2.4で指定されるように有効なBGP Extended Communities属性である8バイトの量です。 そのOSPF例からのルートがVPN-IPv4ルートとしてBGPによって分配されるとき、特定のOSPF例に非NULL Domain Identifierがあるなら、ルートはOSPF例のPrimary Domain Identifierに対応するDomain Identifier Extended Communities属性を運ばなければなりません。 そのOSPF例からのルートがBGPによって分配されるとき、OSPF例のDomain IdentifierがNULLであるなら、Domain Identifier Extended Communities属性は省略されるかもしれません。 あるいはまた、NULL(セクション4.2.4を見る)を表すDomain Identifier Extended Communities属性の値はルートで運ばれるかもしれません。
If the OSPF instances of an OSPF domain are given one or more non- NULL Domain Identifiers, this procedure allows us to determine whether a particular OSPF-originated VPN-IPv4 route belongs to the same domain as a given OSPF instance. We can then determine whether the route should be redistributed to that OSPF instance as an inter- area route or as an OSPF AS-external route. Details can be found in Sections 4.2.4 and 4.2.8.1.
OSPFドメインのOSPF例に1非NULL Domain Identifiersを与えるなら、この手順で、私たちは、与えられたOSPF例として特定のOSPFによって溯源されたVPN-IPv4ルートが同じドメインに属すかどうかと決心できます。 そして、私たちは、ルートが相互領域ルートとして、または、OSPF AS-外部経路としてそのOSPF例に再配付されるべきであるかどうかと決心できます。 詳細はセクション4.2.4と4.2で.1に.8を設立することであるかもしれません。
Rosen, et al. Standards Track [Page 11] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[11ページ]。
4.2.5. Loop Prevention
4.2.5. 輪の防止
4.2.5.1. The DN Bit
4.2.5.1. DNビット
When a type 3 LSA is sent from a PE router to a CE router, the DN bit [OSPF-DN] in the LSA Options field MUST be set. This is used to ensure that if any CE router sends this type 3 LSA to a PE router, the PE router will not redistribute it further.
PEルータからCEルータにタイプ3LSAを送るとき、LSA Options分野のDNビット[OSPF-DN]を設定しなければなりません。 これは、何かCEルータがこのタイプ3LSAをPEルータに送ると、PEルータがさらにそれを再配付しないのを保証するのに使用されます。
When a PE router needs to distribute to a CE router a route that comes from a site outside the latter's OSPF domain, the PE router presents itself as an ASBR (Autonomous System Border Router), and distributes the route in a type 5 LSA. The DN bit [OSPF-DN] MUST be set in these LSAs to ensure that they will be ignored by any other PE routers that receive them.
PEルータが、後者のOSPFドメインの外のサイトから来るルートをCEルータに分配する必要があると、PEルータは、ASBR(自治のSystem Border Router)として出向いて、タイプ5LSAでルートを分配します。 これらのLSAsに彼らがそれらを受けるいかなる他のPEルータによっても無視されるのを保証するようにDNビット[OSPF-DN]を設定しなければなりません。
There are deployed implementations that do not set the DN bit, but instead use OSPF route tagging to ensure that a type 5 LSA generated by a PE router will be ignored by any other PE router that may receive it. A special OSPF route tag, which we will call the VPN Route Tag (see Section 4.2.5.2), is used for this purpose. To ensure backward compatibility, all implementations adhering to this specification MUST by default support the VPN Route Tag procedures specified in Sections 4.2.5.2, 4.2.8.1, and 4.2.8.2. When it is no longer necessary to use the VPN Route Tag in a particular deployment, its use (both sending and receiving) may be disabled by configuration.
DNビットを設定しない実現が配備されますが、代わりにOSPFルートタグ付けを使用して、PEルータで発生するタイプ5LSAがそれを受けるかもしれないいかなる他のPEルータによっても無視されるのを保証してください。 (私たちはVPN Route Tagをタグと呼ぶつもりです)。セクション4.2を見てください。特別なOSPFルートタグ、(.5 .2) このために使用されます。 そして、後方の互換性を確実にするために、この仕様を固く守るすべての実現がデフォルトでVPN Route Tag手順指定されたコネセクション4.2.5.2、4.2を支持しなければならない、.8 .1、4.2 .8 .2。 特定の展開にVPN Route Tagを使用するのはもう必要でないときに、使用(発信と受信の両方)は構成によって無効にされるかもしれません。
4.2.5.2. Use of OSPF Route Tags
4.2.5.2. OSPFルートタグの使用
If a particular VRF in a PE is associated with an instance of OSPF, then by default it MUST be configured with a special OSPF route tag value, which we call the VPN Route Tag. By default, this route tag MUST be included in the Type 5 LSAs that the PE originates (as the result of receiving a BGP-distributed VPN-IPv4 route, see Section 4.2.8) and sends to any of the attached CEs.
PEの特定のVRFがOSPFの例に関連しているなら、デフォルトで、特別なOSPFルートタグ価値でそれを構成しなければなりません。(私たちはVPN Route Tagをそれと呼びます)。 デフォルトで、PEが付属CEsのいずれにも溯源して(BGPによって分配されたVPN-IPv4ルートを受けるという結果と、セクション4.2.8を考えてください)、送るType5LSAsにこのルートタグを含まなければなりません。
The configuration and inclusion of the VPN Route Tag is required for backward compatibility with deployed implementations that do not set the DN bit in type 5 LSAs. The inclusion of the VPN Route Tag may be disabled by configuration if it has been determined that it is no longer needed for backward compatibility.
VPN Route Tagの構成と包含がタイプ5LSAsにDNビットをはめ込まない配備された実現との後方の互換性に必要です。 それはもう後方の互換性に必要でないことを決定したなら、VPN Route Tagの包含が構成によって無効にされるかもしれません。
The value of the VPN Route Tag is arbitrary but must be distinct from any OSPF Route Tag being used within the OSPF domain. Its value MUST therefore be configurable. If the Autonomous System number of the VPN backbone is two bytes long, the default value SHOULD be an automatically computed tag based on that Autonomous System number:
VPN Route Tagの値は、任意ですが、どんなOSPF Route TagともOSPFドメインの中で使用されることで異なっているに違いありません。 したがって、値は構成可能であるに違いありません。 VPN背骨のAutonomous System番号が自動的に計算されたタグがそのAutonomous System番号に基づいたなら2バイト長、デフォルトがSHOULDを評価するということであるなら:
Rosen, et al. Standards Track [Page 12] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[12ページ]。
Tag = <Automatic = 1, Complete = 1, PathLength = 01>
タグは<の自動=1、完全な=1と等しく、PathLengthは01>と等しいです。
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|0|1| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|0|1| ArbitraryTag| AutonomousSystem| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 _AS number of the VPN Backbone_
VPN Backbone_の1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0_AS番号
If the Autonomous System number is four bytes long, then a Route Tag value MUST be configured, and it MUST be distinct from any Route Tag used within the VPN itself.
Autonomous System番号が4バイト長であるなら、Route Tag値を構成しなければなりません、そして、それはVPN自身の中で使用されたどんなRoute Tagとも異なっているに違いありません。
If a PE router needs to use OSPF to distribute to a CE router a route that comes from a site outside the CE router's OSPF domain, the PE router SHOULD present itself to the CE router as an Autonomous System Border Router (ASBR) and SHOULD report such routes as AS-external routes. That is, these PE routers originate Type 5 LSAs reporting the extra-domain routes as AS-external routes. Each such Type 5 LSA MUST contain an OSPF route tag whose value is that of the VPN Route Tag. This tag identifies the route as having come from a PE router. The VPN Route Tag MUST be used to ensure that a Type 5 LSA originated by a PE router is not redistributed through the OSPF area to another PE router.
PEルータが、CEルータのOSPFドメインの外のサイトから来るルートをCEルータに分配するのにOSPFを使用する必要があるなら、Autonomous System Border Router(ASBR)とSHOULDがAS-外部経路のようなルートを報告するとき、PEルータSHOULDはCEルータに出向きます。 すなわち、これらのPEルータはAS-外部経路として余分なドメインルートを報告するType5LSAsを溯源します。 そのようなそれぞれのType5LSA MUSTは値がVPN Route TagのものであるOSPFルートタグを含んでいます。 このタグは、ルートがPEルータから来たことであると認識します。 PEルータによって溯源されたType5LSAがOSPF領域を通して別のPEルータに再配付されないのを保証するのにVPN Route Tagを使用しなければなりません。
4.2.5.3. Other Possible Loops
4.2.5.3. 他の可能な輪
The procedures specified in this document ensure that if routing information derived from a BGP-distributed VPN-IPv4 route is distributed into OSPF, it cannot be redistributed back into BGP as a VPN-IPv4 route, as long as the DN bit and/or VPN route tag is maintained within the OSPF domain. This does not eliminate all possible sources of loops. For example, if a BGP VPN-IPv4 route is distributed into OSPF, then distributed into RIP (where all the information needed to prevent looping is lost), and then distributed back into OSPF, then it is possible that it could be distributed back into BGP as a VPN-IPv4 route, thereby causing a loop.
本書では指定された手順は、BGPによって分配されたVPN-IPv4ルートから得られたルーティング情報がOSPFに分配されるなら、VPN-IPv4ルートとしてそれをBGPに再配付であって戻しできないのを確実にします、DNビット、そして/または、VPNルートタグがOSPFドメインの中で維持される限り。 これは輪のすべての可能な源を排除するというわけではありません。 例えば、BGP VPN-IPv4ルートがOSPFに分配されて、次に、RIP(すべての情報が、どこで輪にするのを防ぐ必要があったかは、無くなっている)に分配されて、次に、OSPFに分配して戻されるなら、VPN-IPv4ルートとしてBGPにそれを分配であって戻しできたのは可能です、その結果、輪を引き起こします。
Therefore, extreme care must be taken if there is any mutual redistribution of routes between the OSPF domain and any third routing domain (i.e., not the VPN backbone). If the third routing domain is a BGP domain (e.g., the public Internet), the ordinary BGP loop prevention measures will prevent the route from reentering the OSPF domain.
したがって、OSPFドメインとどんな3番目の経路ドメイン(すなわち、VPN背骨でない)の間にはも、何かルートの互いの再分配があれば、極端な注意を払わなければなりません。 3番目の経路ドメインがBGPドメイン(例えば、公共のインターネット)であるなら、普通のBGP輪の防止策は、ルートがOSPFドメインに再入するのを防ぐでしょう。
Rosen, et al. Standards Track [Page 13] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[13ページ]。
4.2.6. Handling LSAs from the CE
4.2.6. Ceからの取り扱いLSAs
This section specifies the way in which a PE router handles the OSPF LSAs it receives from a CE router.
このセクションはPEルータがそれがCEルータから受けるOSPF LSAsを扱う方法を指定します。
When a PE router receives, from a CE router, any LSA with the DN bit [OSPF-DN] set, the information from that LSA MUST NOT be used by the route calculation. If a Type 5 LSA is received from the CE, and if it has an OSPF route tag value equal to the VPN Route Tag (see Section 4.2.5.2), then the information from that LSA MUST NOT be used by the route calculation.
PEルータがDNと共にCEルータからどんなLSAも受けるとき、ビット[OSPF-DN]はセットしました、情報。そのLSA MUST NOTから、ルート計算で、使用されます。 CEからType5LSAを受け取って、それでVPN Route Tagと等しいOSPFルートタグ価値がある、(セクション4.2.5を見てください、次に、.2、)情報、そのLSA MUST NOTから、ルート計算で、使用されてください。
Otherwise, the PE must examine the corresponding VRF. For every address prefix that was installed in the VRF by one of its associated OSPF instances, the PE must create a VPN-IPv4 route in BGP. Each such route will have some of the following Extended Communities attributes:
さもなければ、PEは対応するVRFを調べなければなりません。 関連OSPF例の1つによってVRFにインストールされたあらゆるアドレス接頭語のために、PEはBGPのVPN-IPv4ルートを作成しなければなりません。 そのような各ルートには、以下のExtended Communities属性のいくつかがあるでしょう:
- The OSPF Domain Identifier Extended Communities attribute. If
the OSPF instance that installed the route has a non-NULL
primary Domain Identifier, this MUST be present; if that OSPF
instance has only a NULL Domain Identifier, it MAY be omitted.
This attribute is encoded with a two-byte type field, and its
type is 0005, 0105, or 0205. For backward compatibility, the
type 8005 MAY be used as well and is treated as if it were
0005. If the OSPF instance has a NULL Domain Identifier, and
the OSPF Domain Identifier Extended Communities attribute is
present, then the attribute's value field must be all zeroes,
and its type field may be any of 0005, 0105, 0205, or 8005.
- OSPF Domain Identifier Extended Communities属性。 ルートをインストールしたOSPF例が非NULLの第一のDomain Identifierを持っているなら、これは存在していなければなりません。 そのOSPF例にNULL Domain Identifierしかないなら、それは省略されるかもしれません。 タイプは、この属性が2バイトのタイプ分野でコード化されて、0005、0105、または0205です。 後方の互換性において、タイプ8005は、また、使用されるかもしれなくて、まるでそれが0005であるかのように扱われます。 OSPF例にはNULL Domain Identifierがあって、OSPF Domain Identifier Extended Communities属性が存在しているなら、属性の値の分野はすべてゼロであるに違いありません、そして、タイプ分野は0005、0105、0205、または8005年のいずれであるかもしれませんも。
- OSPF Route Type Extended Communities Attribute. This attribute
MUST be present. It is encoded with a two-byte type field, and
its type is 0306. To ensure backward compatibility, the type
8000 SHOULD be accepted as well and treated as if it were type
0306. The remaining six bytes of the Attribute are encoded as
follows:
- OSPFは拡張共同体が結果と考えるタイプを発送します。 この属性は存在していなければなりません。 それは2バイトのタイプ分野でコード化されます、そして、タイプは0306です。 8000SHOULDは、後方の互換性、タイプを確実にするために、また、受け入れられて、まるでそれがタイプ0306であるかのように扱いました。 Attributeの残っている6バイトは以下の通りコード化されます:
+-------+-------+-------+-------+-------+-------+
| Area Number | Route |Options|
| | Type | |
+-------+-------+-------+-------+-------+-------+
+-------+-------+-------+-------+-------+-------+ | 区域番号| ルート|オプション| | | タイプ| | +-------+-------+-------+-------+-------+-------+
* Area Number: 4 bytes, encoding a 32-bit area number. For
AS-external routes, the value is 0. A non-zero value
identifies the route as being internal to the OSPF domain,
and as being within the identified area. Area numbers are
relative to a particular OSPF domain.
* 区域番号: 32ビットの区域番号をコード化する4バイト。 AS-外部経路に、値は0です。 OSPFドメインに内部であることとして特定された領域の中にあることとして非ゼロ値はルートを特定します。 区域番号は特定のOSPFドメインに比例しています。
Rosen, et al. Standards Track [Page 14] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[14ページ]。
* OSPF Route Type: 1 byte, encoded as follows:
* OSPFはタイプを発送します: 以下の通りコード化された1バイト:
** 1 or 2 for intra-area routes (depending on whether the
route came from a type 1 or a type 2 LSA).
** イントラ領域ルート(ルートがタイプ1かタイプ2LSAから来たかどうかによる)への1か2。
** 3 for inter-area routes.
** 3 相互領域ルートに。
** 5 for external routes (area number must be 0).
** 5 外部経路(区域番号は0であるに違いない)に。
** 7 for NSSA routes.
** 7 NSSAルートに。
Note that the procedures of Section 4.2.8 do not make any
distinction between routes types 1, 2, and 3. If BGP installs
a route of one of these types in the VRF, and if that route is
selected for redistribution into OSPF, it will be advertised by
OSPF in either a type 3 or a type 5 LSA, depending on the
domain identifier.
セクション4.2.8の手順がルートの間で少しの区別もしないというメモは1、2、および3をタイプします。 BGPがこれらのタイプのひとりのルートをVRFにインストールして、そのルートが再分配のためにOSPFに選択されると、それはタイプ3かタイプ5LSAのどちらかでOSPFによって広告を出されるでしょう、ドメイン識別子によって。
* Options: 1 byte. Currently, this is only used if the route
type is 5 or 7. Setting the least significant bit in the
field indicates that the route carries a type 2 metric.
* オプション: 1バイト。 現在、これはルートタイプが5か7歳である場合にだけ使用されます。 分野に最下位ビットをはめ込むのは、ルートがメートル法でタイプ2を運ぶのを示します。
- OSPF Router ID Extended Communities Attribute. This OPTIONAL
attribute specifies the OSPF Router ID of the system that is
identified in the BGP Next Hop attribute. More precisely, it
specifies the OSPF Router Id of the PE in the OSPF instance
that installed the route into the VRF from which this route was
exported. This attribute is encoded with a two-byte type
field, and its type is 0107, with the Router ID itself carried
in the first 4 bytes of the value field. The type 8001 SHOULD
be accepted as well, to ensure backward compatibility, and
should be treated as if it were 0107.
- OSPF Router IDは共同体属性を広げました。 このOPTIONAL属性はBGP Next Hop属性で特定されるシステムのOSPF Router IDを指定します。 このルートが輸出されたVRFにルートをインストールしたOSPF例で、より正確に、それはPEのOSPF Router Idを指定します。 この属性は2バイトのタイプ分野でコード化されます、そして、タイプは0107です、ID自体が値の分野の最初の4バイトで運んだRouterと共に。 タイプ8001SHOULDはまた、後方の互換性を確実にするために受け入れられて、まるでそれが0107であるかのように扱われるべきです。
- MED (Multi_EXIT_DISC attribute). By default, this SHOULD be
set to the value of the OSPF distance associated with the
route, plus 1.
- MED(DISCが結果と考えるマルチ_EXIT_)。 デフォルトで、このSHOULD、ルートに関連しているOSPF距離、および1の値に設定されてください。
The intention of all this is the following. OSPF Routes from one site are converted to BGP, distributed across the VPN backbone, and possibly converted back to OSPF routes before being distributed into another site. With these attributes, BGP carries enough information about the route to enable the route to be converted back into OSPF "transparently", just as if BGP had not been involved.
このすべての意志は以下です。 別のサイトに分配される前に、1つのサイトからのOSPF RoutesはBGPに変換されて、VPN背骨の向こう側に分配されて、ことによるとOSPFルートに変換して戻されます。 これらの属性で、BGPはルートのルートが「透明に」OSPFに変換し返されるのを可能にすることができるくらいの情報を運びます、まるでBGPがかかわっているだけではないかのように。
Routes that a PE receives in type 4 LSAs MUST NOT be redistributed to BGP.
PEがタイプ4LSAsで受けるルートをBGPに再配付してはいけません。
Rosen, et al. Standards Track [Page 15] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[15ページ]。
The attributes specified above are in addition to any other attributes that routes must carry in accordance with [VPN].
上で指定された属性は[VPN]に従ってルートが運ばなければならないいかなる他の属性に加えています。
The Site of Origin attribute, which is usually required by [VPN], is OPTIONAL for routes that a PE learns from a CE via OSPF.
Origin属性のSiteはPEがOSPFを通してCEから学ぶルートへのOPTIONALです。(通常、属性は[VPN]によって必要とされます)。
Use of the Site of Origin attribute would, in the case of a multiply homed site (i.e., a site attached to several PE routers), prevent an intra-site route from being reinjected into a site from the VPN backbone. Such a reinjection would not harm the routing, because the route via the VPN backbone would be advertised in a type 3 LSA, and hence would appear to be an inter-area route; the real intra-area route would be preferred. But unnecessary overhead would be introduced. On the other hand, if the Site of Origin attribute is not used, a partitioned site will find itself automatically repaired, since traffic from one partition to the other will automatically travel via the VPN backbone. Therefore, the use of a Site of Origin attribute is optional, so that a trade-off can be made between the cost of the increased overhead and the value of automatic partition repair.
aに関するケースが掛けるコネは家へ帰りました。Origin属性のSiteの使用が防ぐだろう、(すなわち、いくつかのPEルータに添付されたサイト)を位置させてください、そして、VPN背骨からイントラサイトルートがサイトに再注入されるのを防いでください。 そのような再注射はルーティングに害を及ぼさないでしょう、VPN背骨を通したルートが、タイプ3LSAで広告を出して、したがって、相互領域ルートであるように見えるでしょう、したがって。 本当のイントラ領域ルートは好まれるでしょう。 しかし、不要なオーバーヘッドを導入するでしょう。 他方では、仕切られたサイトによって、Origin属性のSiteが使用されていないと、気付くと自動的に修理されているでしょう、1つのパーティションからもう片方までの交通がVPN背骨で自動的に伝わるので。 したがって、Origin属性のSiteの使用は任意です、増加するオーバーヘッドの費用と自動パーティション修理の値の間でトレードオフをすることができるように。
4.2.7. Sham Links
4.2.7. にせのリンク
This section describes the protocol and procedures necessary for the support of "Sham Links," as defined herein. Support for sham links is an OPTIONAL feature of this specification.
このセクションはここに定義されるように「にせのリンク」のサポートに必要なプロトコルと手順について説明します。 にせのリンクのサポートはこの仕様のOPTIONALの特徴です。
4.2.7.1. Intra-Area Routes
4.2.7.1. イントラ領域ルート
Suppose that there are two sites in the same OSPF area. Each site is attached to a different PE router, and there is also an intra-area OSPF link connecting the two sites.
2つのサイトが同じOSPF領域にあると仮定してください。 各サイトは異なったPEルータに添付されます、そして、また、2つのサイトはイントラ領域OSPFリンク接続です。
It is possible to treat these two sites as a single VPN site that just happens to be multihomed to the backbone. This is in fact the simplest thing to do and is perfectly adequate, provided that the preferred route between the two sites is via the intra-area OSPF link (a "backdoor link"), rather than via the VPN backbone. There will be routes between sites that go through the PE routers, but these routes will appear to be inter-area routes, and OSPF will consider them less preferable than the intra-area routes through the backdoor link.
ただたまたま背骨と「マルチ-家へ帰」るただ一つのVPNサイトとしてこれらの2つのサイトを扱うのは可能です。 これは、事実上、する中で最も簡単なことであり、完全に適切です、VPN背骨でというよりむしろイントラ領域のOSPFリンク(「裏口のリンク」)を通して2つのサイトの間の都合のよいルートがあれば。 これらのルートは相互領域ルートであるように見えるでしょう、そして、PEルータに直面しているサイトの間には、ルートがあるでしょうが、OSPFはそれらがイントラ領域ルートほど裏口のリンクを通して望ましくないと考えるでしょう。
If it is desired to have OSPF prefer the routes through the backbone over the routes through the backdoor link, then the routes through the backbone must be appear to be intra-area routes. To make a route through the backbone appear to be an intra-area route, it is necessary to make it appear as if there is an intra-area link
OSPFに裏口のリンクを通してルートの上の背骨を通してルートを好ませるのが、必要であるなら、背骨を通したルートはイントラ領域ルートであるように見えることであるに違いありません。 背骨を通したルートをイントラ領域ルートであるように見えさせるように、まるでイントラ領域のリンクがあるかのように見えるようにするのが必要です。
Rosen, et al. Standards Track [Page 16] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[16ページ]。
connecting the two PE routers. This is what we refer to as a "sham link". (If the two sites attach to the same PE router, this is of course not necessary.)
2つのPEルータを接続します。 これは私たちが「にせのリンク」を呼ぶことです。 (2つのサイトが同じPEルータに付くなら、これはもちろん必要ではありません。)
A sham link can be thought of as a relation between two VRFs. If two VRFs are to be connected by a sham link, each VRF must be associated with a "Sham Link Endpoint Address", a 32-bit IPv4 address that is treated as an address of the PE router containing that VRF. The Sham Link Endpoint Address is an address in the VPN's address space, not the SP's address space. The Sham Link Endpoint Address associated with a VRF MUST be configurable. If the VRF is associated with only a single OSPF instance, and if the PE's router id in that OSPF instance is an IP address, then the Sham Link Endpoint Address MAY default to that Router ID. If a VRF is associated with several OSPF instances, each sham link belongs to a single OSPF instance.
2VRFsの関係としてにせのリンクを考えることができます。 2VRFsがにせのリンクによって接続されるつもりであるなら、それぞれのVRFは「にせのリンク終点アドレス」(そのVRFを含むPEルータのアドレスとして扱われる32ビットのIPv4アドレス)に関連しているに違いありません。 Sham Link Endpoint AddressはSPのアドレス空間ではなく、VPNのアドレス空間においてアドレスです。 Sham Link Endpoint AddressはVRF MUSTと交際しました。構成可能であってください。 VRFがただ一つのOSPF例だけに関連していて、そのOSPF例におけるPEのルータイドがIPアドレスであるなら、Sham Link Endpoint AddressはそのRouter IDをデフォルトとするかもしれません。 VRFがいくつかのOSPF例に関連しているなら、それぞれのにせのリンクはただ一つのOSPF例に属します。
For a given OSPF instance, a VRF needs only a single Sham Link Endpoint Address, no matter how many sham links it has. The Sham Link Endpoint Address MUST be distributed by BGP as a VPN-IPv4 address whose IPv4 address prefix part is 32 bits long. The Sham Link Endpoint Address MUST NOT be advertised by OSPF; if there is no BGP route to the Sham Link Endpoint Address, that address is to appear unreachable, so that the sham link appears to be down.
与えられたOSPF例のために、VRFは独身のSham Link Endpoint Addressだけを必要とします、いくつのにせのリンクを持っても。 BGPはIPv4アドレスの接頭語一部が長さ32ビットであるVPN-IPv4アドレスとしてSham Link Endpoint Addressを分配しなければなりません。 Sham Link Endpoint AddressはOSPFによって広告を出されてはいけません。 Sham Link Endpoint AddressへのBGPルートが全くなければ、そのアドレスは手が届かなく見えることです、にせのリンクが下がっているように見えるように。
4.2.7.2. Creating Sham Links
4.2.7.2. にせのリンクを作成します。
Sham links are manually configured.
にせのリンクは手動で構成されます。
For a sham link to exist between two VRFs, each VRF has to be configured to create a sham link to the other, where the "other" is identified by its sham link endpoint address. No more than one sham link with the same pair of sham link endpoint addresses will ever be created. This specification does not include procedures for single- ended manual configuration of the sham link.
にせのリンクが2VRFsの間に存在するなら、各VRFは、もう片方へのにせのリンクを作成するために構成されなければなりません。(そこでは、「他」がにせのリンク終点アドレスによって特定されます)。 にせのリンク終点アドレスの同じ組との1個未満のにせのリンクが今までに、作成されるでしょう。 この仕様はにせのリンクの手動で終わったシングル構成のための手順を含んでいません。
Note that sham links may be created for any area, including area 0.
にせのリンクが領域0を含むどんな領域にも作成されるかもしれないことに注意してください。
A sham link connecting two VRFs is considered up if and only if a route to the 32-bit remote endpoint address of the sham link has been installed in VRF.
そして、2VRFsを接続するにせのリンクが上がると考えられる、にせのリンクの32ビットのリモート終点アドレスへのルートがVRFにインストールされた場合にだけ。
The sham link endpoint address MUST NOT be used as the endpoint address of an OSPF Virtual Link.
OSPF Virtual Linkの終点アドレスとしてにせのリンク終点アドレスを使用してはいけません。
Rosen, et al. Standards Track [Page 17] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[17ページ]。
4.2.7.3. OSPF Protocol on Sham Links
4.2.7.3. にせのリンクの上のOSPFプロトコル
An OSPF protocol packet sent on a Sham Link from one PE to another must have as its IP source address the Sham Link Endpoint Address of the sender, and as its IP destination address the Sham Link Endpoint Address of the receiver. The packet will travel from one PE router to the other over the VPN backbone, which means that it can be expected to traverse multiple hops. As such, its TTL (Time to Live) field must be set appropriately.
OSPFプロトコルパケットは、1PEから別のPEまでのSham LinkにはIPソースアドレスとして送付者のSham Link Endpoint Addressがなければならないのを転送しました、そして、受信者IPアドレスとして. パケットがそうする受信機のSham Link Endpoint AddressはVPN背骨の上を1つのPEルータからもう片方まで旅行します。背骨は複数のホップを横断すると予想できることを意味します。 そういうものとして、適切にTTL(Liveへの時間)分野を設定しなければなりません。
An OSPF protocol packet is regarded as having been received on a particular sham link if and only if the following three conditions hold:
OSPFプロトコルパケットが特定のにせのリンクの上に受け取られたと見なされる、以下の3つの条件が単に以下を保持します。
- The packet arrives as an MPLS packet, and its MPLS label stack
causes it to be "delivered" to the local sham link endpoint
address.
- パケットはMPLSパケットとして到着します、そして、MPLSラベルスタックはそれがローカルのにせのリンク終点アドレスに「渡されること」を引き起こします。
- The packet's IP destination address is the local sham link
endpoint address.
- パケットの受信者IPアドレスはローカルのにせのリンク終点アドレスです。
- The packet's IP source address is the remote sham link endpoint
address.
- パケットのIPソースアドレスはリモートにせのリンク終点アドレスです。
Sham links SHOULD be treated by OSPF as OSPF Demand Circuits. This means that LSAs will be flooded over them, but periodic refresh traffic is avoided. Note that, as long as the backdoor link is up, flooding the LSAs over the sham link serves no purpose. However, if the backdoor link goes down, OSPF does not have mechanisms enabling the routers in one site to rapidly flush the LSAs from the other site. Therefore, it is still necessary to maintain synchronization among the LSA databases at the two sites, hence the flooding over the sham link.
リンクSHOULDを模造してください。OSPF Demand CircuitsとしてOSPFによって扱われます。 LSAsが彼らの上で水につかりますが、周期的になるのが交通をリフレッシュします。これが意味する、避けられます。 にせのリンクの上にLSAsをあふれさせる場合裏口のリンクが上がっている限り、目的が全く役立たないことに注意してください。 しかしながら、裏口のリンクが落ちるなら、OSPFはメカニズムに1つのサイトのルータがもう片方のサイトからLSAsを急速に洗い流すのを可能にさせません。 したがって、したがって、2つのサイトのLSAデータベース、にせのリンクの上の氾濫の中で同期を維持するのがまだ必要です。
The sham link is an unnumbered point-to-point intra-area link and is advertised as a type 1 link in a type 1 LSA.
にせのリンクの無数の二地点間イントラ領域のリンクであり、タイプ1がタイプ1LSAでリンクするとき、広告を出します。
The OSPF metric associated with a sham link MUST be configurable (and there MUST be a configurable default). Whether traffic between the sites flows via a backdoor link or via the VPN backbone (i.e., via the sham link) depends on the settings of the OSPF link metrics. The metrics can be set so that the backdoor link is not used unless connectivity via the VPN backbone fails, for example.
OSPFメートル法、紛い物に関連づけられて、リンクは構成可能であるに違いありません(構成可能なデフォルトがあるに違いありません)。 裏口のリンクを通してVPN背骨(すなわち、にせのリンクを通した)でサイトの間の交通が流れるかどうかがOSPFリンク測定基準の設定に依存します。 測定基準を設定できるので、例えば、VPN背骨を通した接続性が失敗しない場合、裏口のリンクは使用されていません。
The default Hello Interval for sham links is 10 seconds, and the default Router Dead Interval for sham links is 40 seconds.
にせのリンクへのデフォルトHello Intervalは10秒です、そして、にせのリンクへのデフォルトRouter Dead Intervalは40秒です。
Rosen, et al. Standards Track [Page 18] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[18ページ]。
4.2.7.4. Routing and Forwarding on Sham Links
4.2.7.4. にせのリンクにおけるルート設定と推進
If a PE determines that the next hop interface for a particular route is a sham link, then the PE SHOULD NOT redistribute that route into BGP as a VPN-IPv4 route.
PEが、特定のルートへの次のホップインタフェースがにせのリンクであることを決定するなら、PE SHOULD NOTはVPN-IPv4ルートとしてそのルートをBGPに再配付します。
Any other route advertised in an LSA that is transmitted over a sham link MUST also be redistributed (by the PE flooding the LSA over the sham link) into BGP. This means that if the preferred (OSPF) route for a given address prefix has the sham link as its next hop interface, then there will also be a "corresponding BGP route", for that same address prefix, installed in the VRF. Per Section 4.1.2, the OSPF route is preferred. However, when forwarding a packet, if the preferred route for that packet has the sham link as its next hop interface, then the packet MUST be forwarded according to the corresponding BGP route. That is, it will be forwarded as if the corresponding BGP route had been the preferred route. The "corresponding BGP route" is always a VPN-IPv4 route; the procedure for forwarding a packet over a VPN-IPv4 route is described in [VPN].
また、にせのリンクの上に伝えられるLSAの広告に掲載されたいかなる他のルートもBGPに再配付しなければなりません(にせのリンクの上にLSAをあふれさせるPE)。 これは、また、紛い物に次のホップインタフェースとして与えられたアドレス接頭語のための都合のよい(OSPF)ルートによってリンクされると「対応するBGPルート」があることを意味します、VRFにインストールされたその同じアドレス接頭語のために。 セクション4.1.2に従って、OSPFルートは好まれます。 しかしながら、パケットを進めるとき、紛い物が次のホップインタフェースとしてそのパケットのための都合のよいルートによってリンクされるなら、対応するBGPルートに応じて、パケットを進めなければなりません。 まるで対応するBGPルートが都合のよいルートであったかのようにすなわち、それを進めるでしょう。 いつも「対応するBGPルート」はVPN-IPv4ルートです。 VPN-IPv4ルートの上にパケットを送るための手順は[VPN]で説明されます。
This same rule applies to any packet whose IP destination address is the remote endpoint address of a sham link. Such packets MUST be forwarded according to the corresponding BGP route.
この同じ規則は受信者IPアドレスがにせのリンクのリモート終点アドレスであるどんなパケットにも適用されます。 対応するBGPルートに応じて、そのようなパケットを進めなければなりません。
4.2.8. VPN-IPv4 Routes Received via BGP
4.2.8. BGPを通したVPN-IPv4 Routes Received
This section describes how the PE router handles VPN-IPv4 routes received via BGP.
このセクションはPEルータがどうBGPを通して受け取られたVPN-IPv4ルートを扱うかを説明します。
If a received BGP VPN-IPv4 route is not installed in the VRF, nothing is reported to the CE. A received route will not be installed into the VRF if the BGP decision process regards some other route as preferable. When installed in the VRF, the route appears to be an IPv4 route.
容認されたBGP VPN-IPv4ルートがVRFにインストールされないなら、何もCEに報告されません。 BGP決定の過程が、ある他のルートが望ましいとみなすなら、容認されたルートはVRFにインストールされないでしょう。 VRFにインストールされると、ルートはIPv4ルートであるように見えます。
A BGP route installed in the VRF is not necessarily used for forwarding. If an OSPF route for the same IPv4 address prefix has been installed in the VRF, the OSPF route will be used for forwarding, except in the case where the OSPF route's next-hop interface is a sham link.
VRFにインストールされたBGPルートは推進に必ず使用されるというわけではありません。 同じIPv4アドレス接頭語のためのOSPFルートがVRFにインストールされたなら、OSPFルートは推進に使用されるでしょう、ケースを除いて中OSPFルートの次のホップインタフェースがにせのリンクである。
If a BGP route installed in the VRF is used for forwarding, then the BGP route is redistributed into OSPF and possibly reported to the CEs in an OSPF LSA. The sort of LSA, if any, to be generated depends on various characteristics of the BGP route, as detailed in subsequent sections of this document.
VRFにインストールされたBGPルートが推進に使用されるなら、BGPルートは、OSPFに再配付されて、ことによるとOSPF LSAのCEsに報告されます。 もしあれば発生するべきLSAの種類をBGPルートの様々な特性に依存します、このドキュメントのその後のセクションで詳しく述べられるように。
Rosen, et al. Standards Track [Page 19] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[19ページ]。
The procedure for forwarding a packet over a VPN-IPv4 route is described in [VPN].
VPN-IPv4ルートの上にパケットを送るための手順は[VPN]で説明されます。
In the following, we specify what is reported, in OSPF LSAs, by the PE to the CE, assuming that the PE is not configured to do any further summarization or filtering of the routing information before reporting it to the CE.
以下では、それをCEに報告する前に、私たちはPEが何かさらなる総括をするために構成されないと仮定して、何がOSPF LSAsでPEによってCEに報告されるか、そして、ルーティング情報のフィルタリングを指定します。
When sending an LSA to the CE, it may be necessary to set the DN bit. See Section 4.2.5.1 for the rules regarding the DN bit.
LSAをCEに送るとき、DNビットを設定するのが必要であるかもしれません。 DNに関する規則のための.1が噛み付いたセクション4.2.5を見てください。
When sending an LSA to the CE, it may be necessary to set the OSPF Route Tag. See Section 4.2.5.2 for the rules about setting the OSPF Route Tag.
LSAをCEに送るとき、OSPF Route Tagを設定するのが必要であるかもしれません。 セクション4.2を見てください。.5 .2 OSPF Route Tagを設定することに関する規則のために。
When type 5 LSAs are sent, the Forwarding Address is set to 0.
タイプ5LSAsを送るとき、Forwarding Addressは0に用意ができています。
4.2.8.1. External Routes
4.2.8.1. 外部経路
With respect to a particular OSPF instance associated with a VRF, a VPN-IPv4 route that is installed in the VRF and then selected as the preferred route is treated as an External Route if one of the following conditions holds:
VRFに関連している特定のOSPFインスタンスに関して、以下の条件の1つが持ちこたえるなら、VRFにインストールされて、次に都合のよいルートとして選定されるVPN-IPv4ルートはExternal Routeとして扱われます:
- The route type field of the OSPF Route Type Extended Community
has an OSPF route type of "external".
- OSPF Route Type Extended Communityのルートタイプ分野には、「外部」のOSPFルートタイプがあります。
- The route is from a different domain from the domain of the
OSPF instance.
- ルートはOSPFインスタンスのドメインからの異なったドメインから来ています。
The rules for determining whether a route is from a domain different from that of a particular OSPF instance are the following. The OSPF Domain Identifier Extended Communities attribute carried by the route is compared with the OSPF Domain Identifier Extended Communities attribute(s) with which the OSPF instance has been configured (if any). In general, when two such attributes are compared, all eight bytes must be compared. Thus, two OSPF Domain Identifier Extended Communities attributes are regarded as equal if and only if one of the following three conditions holds:
ルートが特定のOSPFインスタンスのものと異なったドメインから来ているかを決定するための規則は以下です。 ルートで運ばれたOSPF Domain Identifier Extended Communities属性はOSPFインスタンスが構成された(もしあれば)OSPF Domain Identifier Extended Communities属性にたとえられます。 そのような2つの属性が比べるとき、一般に、すべての8バイトを比較しなければなりません。 したがって、2つのOSPF Domain Identifier Extended Communities属性が同じくらい等しい状態で見なされる、以下の3つの条件の1つは単に以下を保持します。
1. They are identical in all eight bytes.
1. それらは8バイトに全部で同じです。
2. They are identical in their lower-order six bytes (value
field), but one attribute has two high-order bytes (type field)
of 0005 and the other has two high-order bytes (type field) of
8005. (This condition is for backward compatibility.)
2. 1つの属性に、0005年の2高位バイト(分野をタイプする)があります、そして、それらは下層階級6バイト(値の分野)が同じですが、もう片方には、8005年の2高位バイト(分野をタイプする)があります。 (この状態は後方の互換性のためのものです。)
Rosen, et al. Standards Track [Page 20] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[20ページ]。
3. The lower-order six bytes (value field) of both attributes
consist entirely of zeroes. In this case, the two attributes
are considered identical irrespective of their type fields, and
they are regarded as representing the NULL Domain Identifier.
3. 両方の属性の下層階級6バイト(値の分野)はゼロから完全に成ります。 この場合、2つの属性がそれらのタイプ分野の如何にかかわらず同じであると考えられます、そして、それらはNULL Domain Identifierを表すと見なされます。
If a VPN-IPv4 route has an OSPF Domain Identifier Extended Communities attribute, we say that that route is in the identified domain. If the value field of the Extended Communities attribute consists of all zeroes, then the identified domain is the NULL domain, and the route is said to belong to the NULL domain. If the route does not have an OSPF Domain Identified Extended Communities attribute, then the route belongs to the NULL domain.
VPN-IPv4ルートにOSPF Domain Identifier Extended Communities属性があるなら、私たちは、そのルートが特定されたドメインにあると言います。 Extended Communities属性の値の分野がすべてのゼロから成るなら、特定されたドメインはNULLドメインです、そして、ルートはNULLドメインに属すと言われています。 ルートにOSPF Domain Identified Extended Communities属性がないなら、ルートはNULLドメインに属します。
Every OSPF instance is associated with one or more Domain Identifiers, though possibly only with the NULL domain identifier. If an OSPF instance is associated with a particular Domain Identifier, we will say that it belongs to the identified domain.
単にことによるとNULLドメイン識別子で関連していますが、あらゆるOSPFインスタンスが1Domain Identifiersに関連しています。 OSPFインスタンスが特定のDomain Identifierに関連しているなら、私たちは、それが特定されたドメインに属すと言うつもりです。
If a VPN-IPv4 route is to be redistributed to a particular instance, it must be determined whether that route and that OSPF instance belong to the same domain. A route and an OSPF instance belong to the same domain if and only if one of the following conditions holds:
VPN-IPv4ルートが特定のインスタンスに再配付することであるなら、そのルートとそのOSPFインスタンスが同じドメインに属すか否かに関係なく、断固としているに違いありません。 ルートとOSPFインスタンスが同じドメインに属す、以下の条件の1つは単に以下を保持します。
1. The route and the OSPF instance each belong to the NULL domain.
1. ルートとOSPFインスタンスはそれぞれNULLドメインに属します。
2. The domain to which the route belongs is the domain to which
the OSPF instance belongs. (That is, the route's Domain
Identifier is equal to the OSPF instance's domain identifier,
as determined by the definitions given earlier in this
section.)
2. ルートが属するドメインはOSPFインスタンスが属するドメインです。 (すなわち、ルートのDomain IdentifierはOSPFインスタンスのドメイン識別子と等しいです、より早くこのセクションで与えられた定義で決定するように。)
If the route and the VRF do not belong to the same domain, the route is treated as an external route.
ルートとVRFが同じドメインに属さないなら、ルートは外部経路として扱われます。
If an external route is redistributed into an OSPF instance, the route may or may not be advertised to a particular CE, depending on the configuration and on the type of area to which the PE/CE link belongs. If the route is advertised, and the PE/CE link belongs to a NSSA area, it is advertised in a type 7 LSA. Otherwise, if the route is advertised, it is advertised in a type 5 LSA. The LSA will be originated by the PE.
OSPFインスタンスに外部経路を再配付するなら、特定のCEにルートの広告を出すかもしれません、構成と、そして、PE/CEリンクが属する領域のタイプに頼っていて。 ルートの広告を出して、PE/CEリンクがNSSA領域のものなら、タイプ7LSAでそれの広告を出します。 さもなければ、ルートを広告に掲載するなら、タイプ5LSAでそれの広告を出します。 LSAはPEによって溯源されるでしょう。
The DN bit (Section 4.2.5.1) MUST be set in the LSA. The VPN Route Tag (see Section 4.2.5.2) MUST be placed in the LSA, unless the use of the VPN Route Tag has been turned off by configuration.
DNが噛み付いた、(セクション4.2 .5 LSAに.1を)設定しなければなりません。 セクション4.2を見てください。VPN Route Tag、(.5 .2を)LSAに置かなければなりません、VPN Route Tagの使用が構成によってオフにされていない場合。
Rosen, et al. Standards Track [Page 21] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[21ページ]。
By default, a type 2 metric value is included in the LSA, unless the options field of the OSPF Route Type Extended Communities attribute of the VPN-IPv4 route specifies that the metric should be type 1.
デフォルトで、タイプ2メートル法の数値はLSAに含まれています、VPN-IPv4ルートのOSPF Route Type Extended Communities属性のオプション分野が、メートル法がタイプ1であるべきであると指定しない場合。
By default, the value of the metric is taken from the MED attribute of the VPN-IPv4 route. If the MED is not present, a default metric value is used. (The default type 1 metric and the default type 2 metric MAY be different.)
デフォルトで、VPN-IPv4ルートのMED属性からメートル法の値を取ります。 MEDが存在していないなら、デフォルトメートル法の数値は使用されています。 デフォルトはメートル法で1つのメートル法のタイプとデフォルトタイプ2をタイプします。(異なるかもしれない、)
Note that this way of handling external routes makes every PE appear to be an ASBR attached to all the external routes. In a multihomed site, this can result in a number of type 5 LSAs containing the same information.
あらゆるPEが、外部経路を扱うこの方法ですべての外部経路に取り付けられたASBRであるように見えることに注意してください。 「マルチ-家へ帰」っているサイトでは、これは同じ情報を含む多くのタイプ5LSAsをもたらすことができます。
4.2.8.2. Summary Routes
4.2.8.2. 概要ルート
If a route and the VRF into which it is imported belong to the same domain, then the route should be treated as if it had been received in an OSPF type 3 LSA. This means that the PE will report the route in a type 3 LSA to the CE. (Note that this case is possible even if the VPN-IPv4 route carries an area number identical to that of the CE router. This means that if an area is "partitioned" such that the two pieces are connected only via the VPN backbone, it appears to be two areas, with inter-area routes between them.)
まるで受け取って、OSPFに、3LSAがタイプしているということであったかのように、それがインポートされるルートとVRFが同じドメインに属すなら、ルートは扱われるべきです。 これは、PEがタイプ3LSAでルートをCEに報告することを意味します。 (VPN-IPv4ルートがCEルータのものと同じ区域番号を運んでも本件が可能であることに注意してください。 これは、領域が2つの断片が単にVPNバックボーンで接続されるように「仕切られる」なら、それが2つの領域であるように見えることを意味します、それらの間には、相互領域ルートがある状態で。)
4.2.8.3. NSSA Routes
4.2.8.3. NSSAルート
NSSA routes are treated the same as external routes, as described in Section 4.2.8.1.
NSSAルートはセクション4.2.8で.1に説明されるように同じように外部経路として扱われます。
5. IANA Considerations
5. IANA問題
Section 11 of [EXTCOMM] calls upon IANA to create a registry for BGP Extended Communities Type Field and Extended Type Field values. Section 4.2.6 of this document assigns new values for the BGP Extended Communities Extended Type Field. These values all fall within the range of values that [EXTCOMM] states "are to be assigned by IANA, using the 'First Come, First Served' policy defined in RFC 2434".
[EXTCOMM]のセクション11は、IANAがBGP Extended Communities Type FieldとExtended Type Field値のための登録を作成するのを要求します。 この.6通のセクション4.2ドキュメントがBGP Extended Communities Extended Type Fieldのために新しい値を割り当てます。 これらの値が[EXTCOMM]州が「'最初に、Come、First Served'方針を使用して、RFC2434で定義されて、IANAによって割り当てられることになっている」値の範囲の中ですべて下落します。
The BGP Extended Communities Extended Type Field values assigned in Section 4.2.6 of this document are as follows:
この.6通のセクション4.2ドキュメントで割り当てられたBGP Extended Communities Extended Type Field値は以下の通りです:
- OSPF Domain Identifier: Extended Types 0005, 0105, and 0205.
- OSPFドメイン識別子: 拡張タイプ0005、0105、および0205。
- OSPF Route Type: Extended Type 0306
- OSPFはタイプを発送します: 拡張タイプ0306
- OSPF Router ID: Extended Type 0107
- OSPF Router ID: 拡張タイプ0107
Rosen, et al. Standards Track [Page 22] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[22ページ]。
6. Security Considerations
6. セキュリティ問題
Security considerations that are relevant in general to BGP/MPLS IP VPNS are discussed in [VPN] and [VPN-AS]. We discuss here only those security considerations that are specific to the use of OSPF as the PE/CE protocol.
[VPN]と[VPN-AS]で一般に、BGP/MPLS IP VPNSに関連しているセキュリティ問題について議論します。 私たちはここでそれらのPE/CEが議定書を作るときOSPFの使用に特定のセキュリティ問題だけについて議論します。
A single PE may be running OSPF as the IGP of the SP backbone network, as well as running OSPF as the IGP of one or more VPNs. This requires the use of multiple, independent OSPF instances, so that routes are not inadvertently leaked between the backbone and any VPN. The OSPF instances for different VPNs must also be independent OSPF instances, to prevent inadvertent leaking of routes between VPNs.
独身のPEはSPバックボーンネットワークのIGPとしてOSPFを実行しているかもしれません、1VPNsのIGPとしての実行しているOSPFと同様に。 これは複数の、そして、独立しているOSPFインスタンスの使用を必要とします、ルートがバックボーンとどんなVPNの間でもうっかり漏らされないように。 また、異なったVPNsのためのOSPFインスタンスは、VPNsの間のルートの不注意な漏出を防ぐためには独立しているOSPFインスタンスでなければなりません。
OSPF provides a number of procedures that allow the OSPF control messages between a PE and a CE to be authenticated. OSPF "cryptographic authentication" SHOULD be used between a PE and a CE. It MUST be implemented on each PE.
OSPFはPEとCEの間のOSPFコントロールメッセージが認証されるのを許容する多くの手順を提供します。 OSPF「暗号の認証」SHOULD、PEとCEの間で使用されてください。 各PEでそれを実装しなければなりません。
In the absence of such authentication, it is possible that the CE might not really belong to the VPN to which the PE assigns it. It may also be possible for an attacker to insert spoofed messages on the PE/CE link, in either direction. Spoofed messages sent to the CE could compromise the routing at the CE's site. Spoofed messages sent to the PE could result in improper VPN routing, or in a denial-of- service attack on the VPN.
そのような認証がないとき、CEが本当にPEがそれを割り当てるVPNに属さないのは、可能です。 また、攻撃者がどちらの方向でも偽造しているメッセージをPE/CEリンクに挿入するのも、可能であるかもしれません。 CEに送られた偽造しているメッセージはCEのサイトでルーティングに感染するかもしれません。 -発信して、PEが不適当なVPNルーティング、または否定に結果になることができたというメッセージであると偽造されて、サービスでは、VPNで攻撃してください。
7. Acknowledgements
7. 承認
Major contributions to this work have been made by Derek Yeung and Yakov Rekhter.
この仕事への主要な貢献はデリックYeungとヤコフRekhterによってされました。
Thanks to Ross Callon, Ajay Singhal, Russ Housley, and Alex Zinin for their review and comments.
彼らのレビューとコメントをロスCallon、Ajay Singhal、ラスHousley、およびアレックス・ジニンをありがとうございます。
8. Normative References
8. 引用規格
[EXTCOMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
[EXTCOMM] サーングリとS.とタッパン、D.とY.Rekhter、「BGPは共同体属性を広げた」RFC4360、2006年2月。
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPFv2]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[OSPF-DN] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a Link
State Advertisement (LSA) Options Bit to Prevent Looping in
BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4576,
June 2006.
[OSPF-DN] ローゼン、E.、Psenak、P.、およびP.Pillay-Esnault、「リンク州の広告(LSA)を使用して、オプションにBGP/MPLS IP仮想私設網(VPNs)で輪にするのを防ぐために噛み付きました」、RFC4576、2006年6月。
Rosen, et al. Standards Track [Page 23] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[23ページ]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[VPN]ローゼンとE.とY.Rekhter、「BGP/MPLS IP仮想私設網(VPNs)」、RFC4364 2006年2月。
9. Informative References
9. 有益な参照
[BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP]Rekhter、Y.、李、T.、およびS.野兎、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC4271 2006年1月。
[RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November
1998.
[裂きます] マルキン、G.は「1998年11月にバージョン2インチ、STD56、RFC2453を裂きます」。
[VPN-AS] Rosen, E., "Applicability Statement for BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4365, February 2006.
[VPN、-、]、ローゼン、E.、「BGP/MPLS IP仮想私設網(VPNs)のための適用性証明」、RFC4365、2月2006日
Authors' Addresses
作者のアドレス
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
マサチューセッツ通りBoxborough、エリックC.ローゼンシスコシステムズInc.1414MA 01719
EMail: erosen@cisco.com
メール: erosen@cisco.com
Peter Psenak Cisco Systems BA Business Center, 9th Floor Plynarenska 1 Bratislava 82109 Slovakia
ピーターPsenakシスコシステムズBaビジネスセンター、9階のPlynarenska1ブラティスラバ82109スロバキア
EMail: ppsenak@cisco.com
メール: ppsenak@cisco.com
Padma Pillay-Esnault Cisco Systems 3750 Cisco Way San Jose, CA 95134
Padma Pillay-Esnaultシスコシステムズ3750コクチマス道サンノゼ(カリフォルニア)95134
EMail: ppe@cisco.com
メール: ppe@cisco.com
Rosen, et al. Standards Track [Page 24] RFC 4577 OSPF for BGP/MPLS IP VPNs June 2006
ローゼン、他 規格はIP VPNs2006年6月にBGP/MPLSのためにRFC4577OSPFを追跡します[24ページ]。
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)によって提供されます。
Rosen, et al. Standards Track [Page 25]
ローゼン、他 標準化過程[25ページ]
一覧
スポンサーリンク
