RFC2650 日本語訳
2650 Using RPSL in Practice. D. Meyer, J. Schmitz, C. Orange, M.Prior, C. Alaettinoglu. August 1999. (Format: TXT=55272 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Meyer
Request for Comments: 2650 Cisco Systems
Category: Informational J. Schmitz
America On-Line
C. Orange
RIPE NCC
M. Prior
Connect
C. Alaettinoglu
USC/ISI
August 1999
コメントを求めるワーキンググループD.マイヤー要求をネットワークでつないでください: 2650年のシスコシステムズカテゴリ: 情報のJ.シュミッツ・アメリカのオンラインC.オレンジの熟しているNCC M.、優先的に、C.Alaettinoglu USC/ISI1999年8月に接続してください。
Using RPSL in Practice
実際には、RPSLを使用します。
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This document is a tutorial on using the Routing Policy Specification Language (RPSL) to describe routing policies in the Internet Routing Registry (IRR). We explain how to specify various routing policies and configurations using RPSL, how to register these policies in the IRR, and how to analyze them using the routing policy analysis tools, for example to generate vendor specific router configurations.
インターネットルート設定Registry(IRR)の方針を発送すると説明するのに、ルート設定Policy Specification Language(RPSL)を使用するとき、このドキュメントはチュートリアルです。 私たちはどのようにRPSLを使用することでどのように様々なルーティング方針と構成を指定するか、そして、どのようにIRRのこれらの方針を登録するか、そして、ルーティング方針解析ツールを使用することでそれらを分析して、例えば業者の特定のルータ構成を発生させるかを説明します。
1 Introduction
1つの序論
This document is a tutorial on RPSL and is targeted towards an Internet/Network Service Provider (ISP/NSP) engineer who understands Internet routing, but is new to RPSL and to the IRR. Readers are referred to the RPSL reference document (RFC 2622) [1] for completeness. It is also good to have that document at hand while working through this tutorial.
このドキュメントは、RPSLの上のチュートリアルであり、インターネット・ルーティングを理解しているインターネット/ネットワークService Provider(ISP/NSP)技術者に向かって狙いますが、RPSLと、そして、IRRに新しいです。 読者は完全性のためのRPSL参考書類(RFC2622)[1]を参照されます。 また、そのドキュメントを近くするのもこのチュートリアルを終えている間、良いです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
Meyer, et al. Informational [Page 1] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[1ページ]のRFC2650
The IRR is a repository of routing policies. Currently, the IRR repository is a set of five repositories maintained at the following sites: the CA*Net registry in Canada, the ANS, CW and RADB registries in the United States of America, and the RIPE registry in Europe. The five repositories are run independently. However, each site exchanges its data with the others regularly (at least once a day and as often as every ten minutes). CW, CA*Net and ANS are private registries which contain the routing policies of the networks and the customer networks of CW, CA*Net, and ANS respectively. RADB and RIPE are both public registries, and any ISP can publish their policies in these registries.
IRRはルーティング方針の倉庫です。 現在、IRR倉庫は以下のサイトで維持された5つの倉庫のセットです: アメリカ合衆国でのカナダ、ANS、CW、およびRADB登録でのカリフォルニア*ネット登録、およびヨーロッパでのRIPE登録。 5つの倉庫が独自に動かされます。 しかしながら、各サイトは定期的(少なくとも1日あたりの同じくらい一度と10分毎と同じくらい頻繁)に他のものとデータを交換します。 CW、カリフォルニア*のネットとANSはそれぞれネットワークのルーティング方針とCW、カリフォルニア*のネット、およびANSの顧客ネットワークを含む個人的な登録です。 RADBとRIPEは両方の公共の登録です、そして、どんなISPもこれらの登録でそれらの方針を発行できます。
The registries all maintain up-to-date copies of one another's data. At any of the sites, the five registries can be inspected as a set. One should refrain from registering his/her data in more than one of the registries, as this practice leads almost invariably to inconsistencies in the data. The user trying to interpret the data is left in a confusing (at best) situation. CW, ANS and CA*Net customers are generally required to register their policies in their provider's registry. Others may register policies either at the RIPE or RADB registry, as preferred.
登録はすべて、お互いのデータの最新のコピーを維持します。 サイトのいずれではも、セットとして5つの登録を点検できます。 登録の1つ以上にその人のデータを登録するのを控えるべきです、この習慣がほぼ不変的にデータにおける矛盾に通じるとき。 データを解釈しようとするユーザは紛らわしい(せいぜい)状況で置き去りにされます。 一般に、CW、ANS、およびカリフォルニア*ネット顧客はそれらのプロバイダーの登録に彼らの方針を登録しなければなりません。 他のものは好まれるようにRIPEかRADB登録に方針を登録するかもしれません。
RPSL is based on RIPE-181 [2, 3], a language used to register routing policies and configurations in the IRR. Operational use of RIPE-181 has shown that it is sometimes difficult (or impossible) to express a routing policy which is used in practice. RPSL has been developed to address these shortcomings and to provide a language which can be further extended as the need arises. RPSL obsoletes RIPE-181.
RPSLはRIPE-181[2、3]に基づいていて、言語は以前はIRRによくルーティング方針と構成を示していました。 RIPE-181の操作上の使用は、実際には使用されるルーティング方針を言い表すのが時々難しい、そして、(不可能)であると示しました。 RPSLは、これらの短所を記述して、さらに必要に応じて広げることができる言語を提供するために開発されました。 RPSLはRIPE-181を時代遅れにします。
RPSL constructs are expressed in one or more database "objects" which are registered in one of the registries described above. Each database object contains some routing policy information and some necessary administrative data. For example, an address prefix routed in the inter-domain mesh is specified in a route object, and the peering policies of an AS are specified in an aut-num object. The database objects are related to each other by reference. For example, a route object must refer to the aut-num object for the AS in which it is originated. Implicitly, these relationships define sets of objects, which can be used to specify policies effecting all members. For example, we can specify a policy for all routes of an ISP, by referring to the AS number in which the routes are registered to be originated.
RPSL構造物は上で説明された登録の1つに登録される「物」という1つ以上のデータベースで言い表されます。 それぞれのデータベース物は何らかのルーティング方針情報といくつかの必要な管理データを含んでいます。 例えば、相互ドメインメッシュで発送されたアドレス接頭語はルート物で指定されます、そして、ASのじっと見る方針はaut-num物で指定されます。 参照でデータベース物は互いに関連します。 例えば、ルート物はそれが溯源されるASについてaut-num物を示さなければなりません。 それとなく、これらの関係は物のセットを定義します。(すべてのメンバーに作用する方針を指定するのに物を使用できます)。 例えば、私たちはISPのすべてのルートに方針を指定できます、ルートが溯源されるために登録されるAS番号を示すことによって。
When objects are registered in the IRR, they become available for others to query using a whois service. Figure 1 illustrates the use of the whois command to obtain the route object for 128.223.0.0/16. The output of the whois command is the ASCII representation of the route object. The syntax and semantics of the route object are
物がIRRに登録されるとき、それらは、whoisサービスを利用することで他のものが質問するように利用可能になります。 図1はルート物を128.223に入手するwhoisコマンドの使用を例証します。.0 .0/16。 whoisコマンドの出力はルート物のASCII表現です。 ルート物の構文と意味論はそうです。
Meyer, et al. Informational [Page 2] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[2ページ]のRFC2650
described in Appendix A.3. Registered policies can also be compared with others for consistency and they can be used to diagnose operational routing problems in the Internet.
Appendix A.3では、説明されます。 また、一貫性のために登録された方針を他のものにたとえることができます、そして、インターネットで操作上のルーティング問題を診断するのに彼らを使用できます。
% whois -h whois.ra.net 128.223.0.0/16
route: 128.223.0.0/16
descr: UONet
descr: University of Oregon
descr: Computing Center
descr: Eugene, OR 97403-1212
descr: USA
origin: AS3582
mnt-by: MAINT-AS3582
changed: meyer@ns.uoregon.edu 19960222
source: RADB
%whois-h whois.ra.net128.223.0.0/16ルート: 128.223.0.0/16descr: UONet descr: オレゴン大学descr: コンピューティングセンターdescr: ユージン、OR97403-1212descr: 米国の起源: 近くAS3582 mnt: MAINT-AS3582は変化しました: meyer@ns.uoregon.edu 19960222ソース: RADB
Figure 1: whois command and a route object.
図1: whoisコマンドとルート物。
The RAToolSet [6] is a suite of tools which can be used to analyze the routing registry data. It includes tools to configure routers (RtConfig), tools to analyze paths on the Internet (prpath and prtraceroute), and tools to compare, validate and register RPSL objects (roe, aoe and prcheck).
RAToolSet[6]はルーティング登録データを分析するのに使用できるひとそろいのツールです。 それはルータ(RtConfig)(インターネット(prpathとprtraceroute)の経路を分析する道具、および比較する道具)がRPSL物(魚卵、aoe、およびprcheck)を有効にして、登録するのを構成するツールを含んでいます。
In the following section, we will describe how common routing policies can be expressed in RPSL. The objects themselves are described in Appendix A. Authoritative information on the IRR objects, however, should be sought in RFC-2622, and authoritative information on general database objects (person, role, and maintainers) and on querying and updating the registry databases, should be sought in RIPE-157 [4]. Section 3.2 describes the use of RtConfig to generate vendor specific router configurations.
以下のセクションで、私たちはRPSLでどう一般的なルーティング方針を言い表すことができるかを説明するつもりです。 物自体はIRR物のAppendix A.Authoritative情報で説明されて、しかしながら、一般的なデータベース物(人、役割、および維持装置)の上にRFC-2622、および信頼できる情報で探されるべきであり、登録データベースを質問して、アップデートするとき、RIPE-157[4]で探されるべきです。 セクション3.2は、業者の特定のルータ構成を発生させるようにRtConfigの使用について説明します。
2 Specifying Policy in RPSL
RPSLの2指定方針
The key purpose of RPSL is to allow you to specify your routing configuration in the public Internet Routing Registry (IRR), so that you and others can check your policies and announcements for consistency. Moreover, in the process of setting policies and configuring routers, you take the policies and configurations of others into account.
RPSLの主要な目的はあなたが公共のインターネットルート設定Registry(IRR)でルーティング設定を指定するのを許容することです、あなたと他のものが一貫性のためのあなたの方針と発表をチェックできるように。 そのうえ、方針を設定して、ルータを構成することの途中に、あなたは他のものの方針と構成を考慮に入れます。
In this section, we begin by showing how some simple peering policies can be expressed in RPSL. We will build on that to introduce various database objects that will be needed in order to register policies in the IRR, and to show how more complex policies can be expressed.
このセクションでは、私たちは、RPSLでどういくつかの簡単なじっと見る方針を言い表すことができるかを示していることによって、始めます。 私たちは、IRRの方針を登録するのに必要である様々なデータベース物を紹介して、どうより複雑な方針を言い表すことができるかを示しているためにそれに建てるつもりです。
Meyer, et al. Informational [Page 3] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[3ページ]のRFC2650
2.1 Common Peering Policies
2.1 一般的なじっと見る方針
The peering policies of an AS are registered in an aut-num object which looks something like that in Figure 2. We will focus on the semantics of the import and export attributes in which peering policies are expressed. We will also describe some of the other key attributes in the aut-num object, but the reader should refer to RFC-2622 or to RIPE-157 for the definitive descriptions.
ASのじっと見る方針は図2のそのように見えるaut-num物に登録されます。 私たちはじっと見る方針が言い表される輸出入属性の意味論に焦点を合わせるつもりです。 また、私たちはaut-num物で他の主要な属性のいくつかについて説明するつもりですが、読者は決定的な記述についてRFC-2622かRIPE-157を参照するべきです。
aut-num: AS2
as-name: CAT-NET
descr: Catatonic State University
import: from AS1 accept ANY
import: from AS3 accept <^AS3+$>
export: to AS3 announce ANY
export: to AS1 announce AS2 AS3
admin-c: AO36-RIPE
tech-c: CO19-RIPE
mnt-by: OPS4-RIPE
changed: orange@ripe.net
source: RIPE
aut-num: AS2、名前として: CATNET descr: 緊張性の州立大学の輸入: AS1から、あらゆる輸入を受け入れてください: AS3から、<^AS3+$>輸出を受け入れてください: AS3に、あらゆる輸出を発表してください: AS1に、AS2 AS3アドミンcを発表してください: AO36-RIPEの科学技術のc: 近くCO19-RIPE mnt: OPS4-RIPEは変化しました: orange@ripe.net ソース: 熟す
Figure 2: Autonomous System Object
図2: 自律システム物
Now consider Figure 3 (AS4 and AS5 in the figure will be discussed later). The peering policies expressed in the AS2 aut-num object in Figure 2 are typical for a small service provider providing connectivity for a customer AS3 and using AS1 for transit. That is, AS2 only accepts announcements from AS3 which:
今度は、図3を考えてください(後で図のAS4とAS5について議論するでしょう)。 小さいサービスプロバイダーにおいて、図2のAS2 aut-num物で言い表されたじっと見る方針は顧客AS3に接続性を供給して、トランジットにAS1を使用することの典型です。 すなわち、AS2がAS3から発表を受け入れるだけである、どれ、:
o are originated in AS3; and
o AS3では、溯源されます。 そして
o have paths composed of only AS3's (^ in <^AS3+$> means that AS3 is
the first member of the path, + means that AS3 occurs one or more
times in the path, and $ means that no other AS can be present in
the path after AS3) (1).
o 経路はAS3(<^AS3+$>の^は、AS3が第1代経路のメンバーであることを意味します、そして、+は、AS3が経路に1回以上起こることを意味します、そして、$は他のどんなASもAS3の後の経路に存在しているはずがないことを意味する)だけの(1)で構成されましたか?
To AS1, AS2 announces only those routes which originate in their AS or in their customer's AS.
AS1に、AS2はそれらのASか彼らの顧客のASに由来するそれらのルートだけを発表します。
AS1--------AS2--------AS3
| |
| |
AS4--------AS5
AS1--------AS2--------AS3| | | | AS4--------AS5
Figure 3: Some Neighboring ASes.
図3: いくつかの隣接しているASes。
Meyer, et al. Informational [Page 4] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[4ページ]のRFC2650
In the example above, "accept ANY" in the import attribute indicates that AS2 will accept any announcements that AS1 sends, and "announce ANY" in the export attribute indicates that any route that AS2 has in its routing table will be passed on to AS3. Assuming that AS1 announces "ANY" to AS2, AS2 is taking full routing from AS1.
例では、上では、輸入属性における「何でも受け入れてください」が、AS2がAS1が発信するというどんな発表も受け入れるのを示します、そして、輸出属性における「何でも発表してください」がAS2が経路指定テーブルに持っているどんなルートもAS3に渡されるのを示します。 AS1がAS2に「ANY」知らせると仮定して、AS2はAS1から完全なルーティングを取っています。
Note that with this peering arrangement, if AS1 adds or deletes route objects, there is no need to update any of the aut-num objects to continue the full routing policy. Added (or deleted) route objects will implicitly update AS1's and AS2's policies.
AS1がルート物を加えるか、または削除するなら、このじっと見るアレンジメントと共に、完全なルーティング政策を存続させるためにaut-num物のどれかをアップデートする必要は全くないことに注意してください。 加えられた(または、削除される)ルート物はそれとなくAS1とAS2の方針をアップデートするでしょう。
While the peering policy specified in Figure 2 for AS2 is common, in practice many peering agreements are more complex. Before we consider more examples, however, let's first consider the aut-num object itself. Note that it is just a set of attribute labels and values which can be submitted to one of the registry databases. This particular object is specified as being in (or headed for) the RIPE registry (see the last line in Figure 2). The source should be specified as one of ANS, CANET, CW, RADB, or RIPE depending on the registry in which the object is maintained. The source attribute must be specified in every database object.
図2でAS2に指定されたじっと見る方針は一般的ですが、実際には、多くのじっと見る協定が、より複雑です。 しかしながら、より多くの例を考える前に、最初に、aut-num物自体を考えましょう。 それが登録データベースの1つに提出できるちょうど1セットの属性ラベルと値であることに注意してください。 この特定の物は(または、向かいます)RIPE登録にあると指定されます(図2の最終ラインを見てください)。 ソースは物が維持される登録によるANS、CANET、CW、RADB、またはRIPEの1つとして指定されるべきです。 あらゆるデータベース物でソース属性を指定しなければなりません。
It is also worth noting that this object is "maintained by" OPS4-RIPE (the value of the mnt-by attribute), which references a "mntner" object. Because the aut-num object may be used for router configuration and other operational purposes, the readers need to be able to count on the validity of its contents. It is therefore required that a mntner be specified in the aut-num and in most other database objects, which means you must create a mntner object before you can register your peering policies. For brief information on the "mntner" object and object writeability, see Appendix A of this document. For more extensive information on how to set up and use a mntner to protect your database objects, see Section 2.3 of RIPE-157.
また、この物があることに注意する価値が、OPS4-RIPEが(近くmnt属性の値)であると「維持した」ということです。("mntner"という参照は)を反対させます)。 aut-num物がルータ構成と他の操作上の目的に使用されるかもしれないので、読者は、コンテンツの正当性を頼りにすることができる必要があります。 したがって、mntnerがaut-numで指定されるのが必要であり、他のほとんどのデータベース物では、どれが、あなたがあなたの前でmntner物を作成しなければならないことを意味するかがあなたのじっと見る方針を登録できます。 "mntner"物と物のwriteabilityの簡潔な情報に関しては、このドキュメントのAppendix Aを見てください。 あなたのデータベース物を保護するのにmntnerをセットアップして、どう使用するかの、より大規模な情報に関しては、RIPE-157のセクション2.3を見てください。
2.2 ISP Customer - Transit Provider Policies
2.2ISP顧客--トランジットプロバイダー方針
It is not uncommon for an ISP to acquire connectivity from a transit provider which announces all routes to it, which it in turn passes on to its customers to allow them to access hosts on the global Internet. Meanwhile, the ISP will generally announce the routes of its customers networks to the transit ISP, making them accessible on the global Internet. This is the service that is specified in Figure 2 for AS3.
ISPがすべてのルートを発表するトランジットプロバイダーからそれまでの接続性を取得するのは、珍しくはありません。(それは、彼らが世界的なインターネットでホストにアクセスするのを許容するために順番に接続性を顧客に渡します)。 その間、一般に、ISPは顧客ネットワークのルートをトランジットISPに発表するでしょう、世界的なインターネットでそれらをアクセスしやすくして。 これは図2でAS3に指定されるサービスです。
Consider again Figure 3. Suppose now that AS2 wants to provide the same service to AS4. Clearly, it would be easy to modify the import and export lines in the aut-num object for AS2 (Figure 2) to those shown in Figure 4.
もう一度図3を考えてください。 AS2がAS4に対する同じサービスを提供したがっているので、思ってください。 明確に、AS2(図2)のためにaut-num物で図4に示されたものに輸出入線を変更するのは簡単でしょう。
Meyer, et al. Informational [Page 5] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[5ページ]のRFC2650
import: from AS1 accept ANY
import: from AS3 accept <^AS3+$>
import: from AS4 accept <^AS4+$>
export: to AS3 announce ANY
export: to AS4 announce ANY
export: to AS1 announce AS2 AS3 AS4
輸入: AS1から、あらゆる輸入を受け入れてください: AS3から、<^AS3+$>輸入を受け入れてください: AS4から、<^AS4+$>輸出を受け入れてください: AS3に、あらゆる輸出を発表してください: AS4に、あらゆる輸出を発表してください: AS1に、AS2 AS3 AS4を発表してください。
Figure 4: Policy for AS3 and AS4 in the AS2 as-num object
図4: numとしてのAS2物のAS3とAS4のための方針
These changes are trivial to make of course, but clearly as the number of AS2 customers grows, it becomes more difficult to keep track of, and to prevent errors. Note also that if AS1 is selective about only accepting routes from the customers of AS2 from AS2, the aut-num object for AS1 would have to be adjusted to accommodate AS2's new customer.
これらの変化はもちろん作るために些細ですが、AS2顧客の数が明確に成長するのに従って、動向をおさえて、誤りを防ぐのは、より難しくなります。 また、AS1がAS2の顧客からAS2からルートを受け入れることだけに関して選択しているなら、AS1のためのaut-num物がAS2の新しい顧客を収容するように調整されなければならないことに注意してください。
By using the RPSL "as-set" object, we can simplify this significantly. In Figure 5, we describe the customers of AS2. Having this set to work with, we can now rewrite the policies in Figure 2 as shown in Figure 6.
RPSL「資産」物を使用することによって、私たちはこれをかなり簡素化できます。 図5では、私たちはAS2の顧客について説明します。 働いているこのセットを持っていて、私たちは現在、図6に示されるように図2の方針を書き直すことができます。
as-set: AS2:AS-CUSTOMERS
members: AS3 AS4
changed: orange@ripe.net
source: RIPE
資産: AS2: AS-CUSTOMERSメンバー: AS3 AS4は変化しました: orange@ripe.net ソース: 熟す
Figure 5: The as-set object
図5: 資産物
import: from AS1 accept ANY
import: from AS2:AS-CUSTOMERS accept <^AS2:AS-CUSTOMERS+$>
export: to AS2:AS-CUSTOMERS announce ANY
export: to AS1 announce AS2 AS2:AS-CUSTOMERS
輸入: AS1から、あらゆる輸入を受け入れてください: AS2から: AS-CUSTOMERSは<^AS2: AS-CUSTOMERS+$>輸出を受け入れます: AS2に: AS-CUSTOMERSはどんな輸出も発表します: AS1に、AS2 AS2: AS-CUSTOMERSを発表してください。
Figure 6: Policy in the AS2 aut-num object for all AS2 customers
図6: すべてのAS2顧客のためのAS2 aut-num物の方針
Note that if the aut-num object for AS1 contains the line:
AS1のためのaut-num物が線を含むなら、それに注意してください:
import: from AS2 accept <^AS2+ AS2:AS-CUSTOMERS*$>
輸入: AS2から、<^AS2+AS2を受け入れてください: AS-CUSTOMERS*$>。
then no changes will need to be made to the aut-num objects for AS1 or AS2 as the AS2 customer base grows. The AS numbers for new customers can simply be added to the as-set AS2:AS-CUSTOMERS, and everything will work as for the existing customers. Clearly in terms of readability, scalability and maintainability, this is a far better mechanism when compared to adding policy for the customer AS's to the aut-num objects directly. The policy in this particular example states that AS1 will accept route announcements from AS2 in which the first element of the path is AS2, followed by more occurrences of
そして、どんな変化も、AS2顧客ベースが発展するのでAS1かAS2のためにaut-num物に作られている必要がないでしょう。 単にAS2: 資産AS-CUSTOMERSに新しい顧客のAS番号を加えることができます、そして、すべてが既存の顧客のように働くでしょう。 明確に読み易さ、スケーラビリティ、および保守性に関して、顧客ASのために直接aut-num物に方針を追加すると比べると、これははるかに良いメカニズムです。 この特定の例の方針は、AS1が経路の最初の要素が、より多くの発生によっていうことになられたどれのAS2であるかでAS2からルート発表を受け入れると述べます。
Meyer, et al. Informational [Page 6] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[6ページ]のRFC2650
AS2, and then 0 or more occurrences of any AS2 customer (e.g. any member of the as-set AS2:AS-CUSTOMERS).
AS2、およびそして、どんなAS2顧客(資産AS2の例えばどんなメンバーも: AS-CUSTOMERS)の0回以上の発生。
Alternatively, one may wish to limit the routes one accepts from a peer, especially if the peer is a customer. This is recommended for several reasons, such as preventing the improper use of unassigned address space, and of course malicious use of another organization's address space.
あるいはまた、特に同輩が顧客であるなら1つが同輩から受け入れるルートを制限したがっているかもしれません。 これはいくつかの理由で推薦されます、割り当てられなかったアドレス空間の不適当な使用、およびもちろん別の組織のアドレス空間の悪意がある使用を防ぐのなどように。
Such filtering can be expressed in various ways in RPSL. Suppose the address space 7.7.0.0/16 has been allocated to the ISP managing AS3 for assignment to its customers. AS3 may want to announce part or all of this block on the global Internet. Suppose AS2 wants to be certain that it only accepts announcements from AS3 for address space that has been properly allocated to AS3. AS2 might then modify the AS3 import line in Figure 2 to read:
いろいろRPSLでそのようなフィルタリングを言い表すことができます。 アドレス空間7.7.0であるなら、課題のために顧客にAS3を管理するISPに.0/16を割り当てました。 AS3は部分か優に世界的なインターネットのこのブロックを発表したがっているかもしれません。 AS2が適切にAS3に割り当てられたアドレス空間のためにAS3から発表を受け入れるだけであるのを確信するようになりたいと仮定してください。 次に、AS2は読むように図2のAS3輸入線を変更するかもしれません:
import: from AS3 accept { 7.7.0.0/16^16-19 }
輸入: AS3から、受け入れてください。{ 7.7.0.0/16^16-19 }
which states that route announcements for this address block will be accepted from AS3 if they are of length upto /19. This of course will have to be modified if and when AS3 gets more address space. Moreover, it is again clear that for an ISP with a growing or changing customer base, this mechanism will not scale well.
このあて先ブロックのためのルート発表がそれらが長さのupto /19のものであるならAS3から受け入れられると述べます。 AS3が、より多くのアドレス空間を得ると、これはもちろん変更されなければならないでしょう。 そのうえ、再び、成長か変化顧客ベースがあるISPのために、このメカニズムがよく比例しないのは、明確です。
route-set: AS2:RS-ROUTES:AS3
members: 7.7.0.0/16^16-19
changed: orange@ripe.net
source: RIPE
ルートセット: AS2:RS-ROUTES:AS3メンバー: 7.7.0.0/16^16-19は変化しました: orange@ripe.net ソース: 熟す
Figure 7: The route-set object
図7: ルートセット物
Luckily RPSL supports the notion of a "route-set" which, as shown in Figure 7, can be used to specify the set of routes that will be accepted from a given customer. Given this set (and a similar one for AS4), the manager of AS2 can now filter on the address space that will be accepted from their customers by modifying the import lines in the AS2 aut-num object as shown in Figure 8.
運よくRPSLは与えられた顧客から受け入れられるルートのセットを指定するのに図7に示されるように使用できる「ルートセット」の概念を支持します。 これを考えて、セットしてください(そして、AS4のための同様のもの)、とAS2のマネージャは現在、彼らの顧客から図8に示されるようにAS2 aut-num物で輸入線を変更することによって受け入れられるアドレス空間でフィルターにかけることができます。
import: from AS1 accept ANY
import: from AS3 accept AS2:RS-ROUTES:AS3
import: from AS4 accept AS2:RS-ROUTES:AS4
export: to AS2:AS-CUSTOMERS announce ANY
export: to AS1 announce AS2 AS2:AS-CUSTOMERS
輸入: AS1から、あらゆる輸入を受け入れてください: AS3から、AS2:RS-ROUTES:AS3輸入を受け入れてください: AS4から、AS2:RS-ROUTES:AS4輸出を受け入れてください: AS2に: AS-CUSTOMERSはどんな輸出も発表します: AS1に、AS2 AS2: AS-CUSTOMERSを発表してください。
Figure 8: Policy in the AS2 aut-num object for address based
filtering on AS2 customers
エイト環: AS2で顧客をフィルターにかけながら基づくアドレスのためのAS2 aut-num物の方針
Meyer, et al. Informational [Page 7] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[7ページ]のRFC2650
Note that this is now only slightly more complex than the example in Figure 6. Furthermore, nothing need be changed in the AS2 aut-num object due to address space changes for a customer, and this filtering can be supported without any changes to the AS1 aut-num object. The additional complexity is due to the two route set names being different, otherwise we could have combined the two import statements into one. Please note that the set names are constructed hierarchically. The first AS number denotes whose sets these are, and the last AS number parameterize these sets for each peer. RPSL allows the peer's AS number to be replaced by the keyword PeerAS.
これが図6の例より現在わずかにだけ複雑であることに注意してください。 その上、アドレス空間変化のため顧客のためにAS2 aut-num物で何も変える必要はありません、そして、AS1 aut-num物への少しも変化なしでこのフィルタリングをサポートできます。 追加複雑さは2つの異なったルートセット名のためです。さもなければ、私たちは2つの輸入声明を1つに結合したかもしれません。 セット名は階層的で構成されます。 最初のAS番号はこれらがだれのセットであるか、そして、最後のASを指示します。数は各同輩のためにこれらのセットをparameterizeします。 RPSLは、同輩のAS番号がキーワードPeerASに取り替えられるのを許容します。
Hence,
したがって
import: from AS3 accept AS2:RS-ROUTES:PeerAS
import: from AS4 accept AS2:RS-ROUTES:PeerAS
輸入: AS3から、AS2:RS-ROUTES:PeerAS輸入を受け入れてください: AS4から、AS2:RS-ROUTES:PeerASを受け入れてください。
has the same meaning as the corresponding import statements in Figure 6. This lets us combine the two import statements into one as shown in Figure 9.
図6での対応する輸入声明と同じ意味を持っています。 これで、私たちは図9に示されるように2つの輸入声明を1つに結合できます。
import: from AS1 accept ANY
import: from AS2:AS-CUSTOMERS accept AS2:RS-ROUTES:PeerAS
export: to AS2:AS-CUSTOMERS announce ANY
export: to AS1 announce AS2 AS2:AS-CUSTOMERS
輸入: AS1から、あらゆる輸入を受け入れてください: AS2から: AS-CUSTOMERSはAS2:RS-ROUTES:PeerAS輸出を受け入れます: AS2に: AS-CUSTOMERSはどんな輸出も発表します: AS1に、AS2 AS2: AS-CUSTOMERSを発表してください。
Figure 9: Policy in the AS2 aut-num object using PeerAS
図9: PeerASを使用するAS2 aut-num物の方針
2.3 Including Interfaces in Peering Definitions
2.3 じっと見る定義にインタフェースを含んでいること。
In the above examples peerings were only given among ASes. However, the peerings may be described in much more detail by RPSL, where peerings can be specified between physical routers using IP addresses in the import and export attributes. Figure 10 shows a simple example in which AS1 and AS2 are connected to an exchange point IX. While AS1 has only one connection to the exchange point via a router interface with IP address 7.7.7.1, AS2 has two different connections with IP address 7.7.7.2 and 7.7.7.3. The first AS may then define its routing policy in more detail by specifying its boundary router.
上記の例では、ASesの中でpeeringsを与えただけです。 しかしながら、RPSLは多くのその他の詳細でpeeringsについて説明するかもしれません。そこでは、物理的なルータの間で輸出入属性にIPアドレスを使用することでpeeringsを指定できます。 図10はAS1とAS2が交換ポイントIXに接続される簡単な例を示しています。 AS2には、IPアドレス7.7.7.2と7.7との2つの異なった関係があります。IPアドレスとのルータインタフェースを通して交換ポイントにはAS1が1つの接続しかいない、7.7、.7、.1、.7 .3。 そして、最初のASは、さらに詳細に境界ルータを指定することによって、ルーティング方針を定義するかもしれません。
+--------------------+ +--------------------+
| 7.7.7.1 |-----+ +-----| 7.7.7.2 |
| | | | | |
| AS1 | ======== | AS2 |
| | IX | | |
| | +-----| 7.7.7.3 |
+--------------------+ +--------------------+
+--------------------+ +--------------------+ | 7.7.7.1 |-----+ +-----| 7.7.7.2 | | | | | | | | AS1| ======== | AS2| | | IX| | | | | +-----| 7.7.7.3 | +--------------------+ +--------------------+
Figure 10: Including interfaces in peerings definitions
図10: peerings定義にインタフェースを含んでいます。
Meyer, et al. Informational [Page 8] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[8ページ]のRFC2650
aut-num: AS1
import: from AS2 at 7.7.7.1 accept <^AS2+$>
aut-num: AS1輸入: 7.7におけるAS2、.7、.1は<^AS2+$>を受け入れます。
Because AS1 has only one connection to the exchange point in this example, this specification does not differ from that in which no boundary router is specified. However, AS1 might want to choose to accept only those announcements from AS2 which come from the router with IP address 7.7.7.2 and disregard those announcements from router 7.7.7.3. AS1 can specify this routing policy as follows:
交換ポイントにはAS1がこの例に1つの接続しかいないので、この仕様は境界ルータが全く指定されないそれと異なっていません。 しかしながら、AS1が、ルータからそれらの発表を無視しにIPアドレス7.7.7.2があるルータから来るAS2からそれらの発表だけを受け入れるのを選びたがっているかもしれない、7.7、.7、.3 AS1は以下のこのルーティング方針を指定できます:
aut-num: AS1
import: from AS2 7.7.7.2 at 7.7.7.1 accept <^AS2+$>
aut-num: AS1輸入: AS2 7.7.7、7.7における.2、.7、.1は<^AS2+$>を受け入れます。
By selecting certain pairs of routers in a peering specification, others can be denied. If no routers are included in a policy clause then it is assumed that the policy applies to all peerings among the ASes involved.
じっと見る仕様でルータのある組を選択することによって、他のものは否定される場合があります。 ルータが全く保険約款に含まれていないなら、方針がASesの中のpeeringsがかかわったすべてに適用されると思われます。
2.4 Describing Simple Backup Connections
2.4 簡単なバックアップコネクションズについて説明すること。
The specification of peerings among ASes is not limited to one router for each AS. In figure 10 one of the two connections of AS2 to the exchange point IX might be used as backup in case the other connection fails. Let us assume that AS1 wants to use the connection to router 7.7.7.2 of AS2 during regular operations, and router 7.7.7.3 as backup. In a router configuration this may be done by setting a local preference. The equivalent in RPSL is a corresponding action definition in the peering description. The action definitions are inserted directly before the accept keyword.
ASesの中のpeeringsの仕様は各ASあたり1つのルータに制限されません。 10図では、もう片方の接続が失敗するといけないので、交換ポイントIXへのAS2の2つの接続のひとりはバックアップとして使用されるかもしれません。 AS1がルータに接続を使用したがっていると仮定しよう、7.7、.7、.2、正常な操業、およびルータの間のAS2、7.7、.7、.3、バックアップとして。 ルータ構成では、地方の優先を設定することによって、これをするかもしれません。 RPSLの同等物はじっと見る記述への対応する動作定義です。 動作定義が直接以前挿入される、キーワードを受け入れてください。
aut-num: AS1
import: from AS2 7.7.7.2 at 7.7.7.1 action pref=10;
from AS2 7.7.7.3 at 7.7.7.1 action pref=20;
accept <^AS2+$>
aut-num: AS1輸入: AS2、7.7 .7 .2 7.7.7.1動作pref=10で。 AS2、7.7 .7 .3 7.7.7.1動作pref=20で。 <^AS2+$>を受け入れてください。
pref is opposite to local-pref in that the smaller values are preferred over larger values. Actions may also be defined without specifying IP addresses of routers. If no routers are included in the policy clause then it is assumed that the actions are carried out for all peerings among the ASes involved.
prefは、より大きい値より小さい値が好まれるという点において地方のprefに反対です。 また、ルータのIPアドレスを指定しないで、動作は定義されるかもしれません。 ルータが全く保険約款に含まれていないなら、動作がASesの中のpeeringsがかかわったすべてのために行われると思われます。
In the previous example AS1 controls where it sends its traffic and which connection is used as backup. However, AS2 may also define a backup connection in an export clause:
前の例では、AS1は、交通をどこに送るか、そして、どの接続がバックアップとして使用されるかを制御します。 しかしながら、また、AS2は輸出節でバックアップ接続を定義するかもしれません:
Meyer, et al. Informational [Page 9] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[9ページ]のRFC2650
aut-num: AS2
export: to AS1 7.7.7.1 at 7.7.7.2 action med=10;
to AS1 7.7.7.1 at 7.7.7.3 action med=20;
announce <^AS2+$>
aut-num: AS2は輸出します: AS1 7.7.7と、7.7.7.2動作医学の.1は10と等しいです。 AS1 7.7.7と、7.7.7.3動作医学の.1は20と等しいです。 <^AS2+$>を発表してください。
The definition given here for AS2 is the symmetric counterpart to the routing policy of AS1. The selection of routing information is done by setting the multi exit discriminator metric med. Actually, med metrics will not be used in practice like this; they are more suitable for load balancing including backups. For more details on med metrics refer to the BGP-4 RFC [7]. To use the med to achieve load balancing, one often sets it to the "IGP metric". This is specified in RPSL as:
AS2のためにここに与えられた定義はAS1のルーティング方針への左右対称の対応者です。 マルチ出口弁別器を設定することによって、メートル法でルーティング情報の選択をします。医学。 実際に、医学の測定基準は実際にはこのように使用されないでしょう。 それらはバックアップを含むロードバランシングにより適しています。 医学の測定基準に関するその他の詳細について、BGP-4 RFC[7]を参照してください。 ロードバランシングを達成するのに医学を使用するために、1つがしばしばそれを設定する、「IGPメートル法です」。 これは以下としてRPSLで指定されます。
aut-num: AS2
export: to AS1 action med=igp_cost; announce <^AS2+$>
aut-num: AS2は輸出します: AS1動作医学の=igp_費用に。 <^AS2+$>を発表してください。
Hence, both routers will set the med to the IGP metric at that router, causing some routes to be preferred at one of the routers and other routes at the other router.
したがって、両方のルータはそのルータにおけるメートル法のIGPへの医学を設定するでしょう、いくつかのルートがルータと他のルートの1つでもう片方のルータで好まれることを引き起こして。
2.5 Multi-Home Routing Policies using the community Attribute
2.5 共同体Attributeを使用するマルチホームルート設定Policies
RFC 1998 [9] describes the use of the BGP community attribute to provide support for load balancing and backup connections of multi- homed autonomous systems. In this section, we use stepwise refinement of an example to illustrate how those policies might be specified using RPSL.
RFC1998[9]がロードバランシングのサポートを提供して、接続のバックアップをとるBGP共同体属性の使用について説明する、マルチ、家へ帰り、自律システムこのセクションでは、私たちは、それらの方針がRPSLを使用することでどう指定されるかもしれないかを例証するのに例の段階的詳細化を使用します。
The basic premise of RFC 1998 is to use the BGP community attribute to allow a customer to configure the BGP "LOCAL_PREF" on a provider's routers. This will allow the customer to influence the provider's route selection, normally by lowering the BGP "LOCAL_PREF" to indicate backup arrangements.
RFC1998の根本的な前提は、顧客がプロバイダーのルータでBGP「地方の_PREF」を構成するのを許容するのにBGP共同体属性を使用することになっています。 これで、顧客はプロバイダーのルート選択に影響を及ぼすことができるでしょう、通常、バックアップアレンジメントを示すためにBGP「地方の_PREF」を下ろすことによって。
In this example, we illustrate how AS1 (the provider) might specify their policy so that a customer (AS4) connected to two of AS1's direct customers (AS2 and AS3) might signal to AS1 which connection is to be preferred.
この例では、私たちはAS1の2人の直接の顧客(AS2とAS3)に関連づけられた顧客(AS4)がそれの接続が好まれることになっているAS1に合図できるようにAS1(プロバイダー)がどうそれらの方針を指定するかもしれないかを例証します。
AS1's base policy is to only accept routes from customers that are originated by the customer, or by the customer's customers. This leads to a policy such as:
AS1のベース方針は顧客、または自分の顧客によって溯源される顧客からルートを受け入れるだけであることです。 これは以下などの方針に通じます。
Meyer, et al. Informational [Page 10] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[10ページ]のRFC2650
aut-num: AS1
import: from AS2
accept (AS2 OR AS4) AND <^AS2+ AS4*$>
import: from AS3
accept (AS3 OR AS4) AND <^AS3+ AS4*$>
import: from AS5
accept AS5 AND <^AS5+$>
aut-num: AS1輸入: AS2から、(AS2 OR AS4)と<^AS2+AS4*$>輸入を受け入れてください: AS3から、(AS3 OR AS4)と<^AS3+AS4*$>輸入を受け入れてください: AS5から、AS5 AND<^AS5+$>を受け入れてください。
Note that AS4 is a customer of AS2 and AS3, and AS5 does not have its own customers.
AS5には、AS4がAS2とAS3の顧客であることに注意してください。そうすれば、それ自身の顧客がいません。
Now suppose we want to add some policy to describe that if a customer tags a route with community 1:1 then AS1 will act on this to reduce the BGP "LOCAL_PREF" by 10.
今度は、顧客が1:1の当時のAS1がBGP「地方の_PREF」を10減少させるためにこれに行動させる共同体をルートにタグ付けするならそれについて説明するために何らかの方針を加えたいと思うと仮定してください。
aut-num: AS1
import: from AS2
action pref=10;
accept (AS2 OR AS4) AND <^AS2+ AS4*$>
AND community.contains(1:1)
import: from AS2
action pref=0;
accept (AS2 OR AS4) AND <^AS2+ AS4*$>
import: from AS3
action pref=10;
accept (AS3 OR AS4) AND <^AS3+ AS4*$>
AND community.contains(1:1)
import: from AS3
action pref=0;
accept (AS3 OR AS4) AND <^AS3+ AS4*$>
import: from AS5
action pref=10;
accept AS5 AND <^AS5+$> AND community.contains(1:1)
import: from AS5
action pref=0;
accept AS5 AND <^AS5+$>
aut-num: AS1はインポートします: AS2動作pref=10から。 (AS2 OR AS4)と<^AS2+AS4*$>とcommunity.contains(1:1)輸入を受け入れてください: AS2動作pref=0から。 (AS2 OR AS4)と<^AS2+AS4*$>輸入を受け入れてください: AS3動作pref=10から。 (AS3 OR AS4)と<^AS3+AS4*$>とcommunity.contains(1:1)輸入を受け入れてください: AS3動作pref=0から。 (AS3 OR AS4)と<^AS3+AS4*$>輸入を受け入れてください: AS5動作pref=10から。 AS5 AND<^AS5+$>とcommunity.contains(1:1)輸入を受け入れてください: AS5動作pref=0から。 AS5 AND<^AS5+$>を受け入れてください。
We can see here that basically we are adding identical statements for each peering to the policy. This is the ideal candidate for RPSL's refine statement. This will make the policy more concise and avoid some of the potential for errors as more peering statements are added in the future:
私たちは、基本的に、方針への各じっと見るために同じ声明を加えているのをここを見ることができます。 RPSLのものが声明を洗練するので、これは理想的な候補です。 さらにじっと見ている声明が将来加えられるとき、これは、方針をより簡潔にして、誤りの何らかの可能性を避けるでしょう:
Meyer, et al. Informational [Page 11] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[11ページ]のRFC2650
aut-num: AS1
import: {
from AS-ANY
action pref=10;
accept community.contains(1:1);
from AS-ANY
action pref=0;
accept ANY;
} refine {
from AS2 accept (AS2 OR AS4) AND <^AS2+ AS4*$>;
from AS3 accept (AS3 OR AS4) AND <^AS3+ AS4*$>;
from AS5 accept AS5 AND <^AS5+$>;
}
aut-num: AS1はインポートします: いずれのAS動作pref=10から; community.contains(1:1)を受け入れてください、; いずれのAS動作pref=0から; 何でも受け入れてください;洗練される。AS2から、(AS2 OR AS4)と<^AS2+AS4*$>を受け入れてください; AS3から、(AS3 OR AS4)と<^AS3+AS4*$>を受け入れてください; AS5から、AS5 AND<^AS5+$>を受け入れてください;。
Now, we can clearly see that any route that has been accepted from a customer that contains the community 1:1 will have it's local preference value reduced by 10.
1:1は、今、私たちが、共同体を含む顧客から受け入れられたどんなルートも10減少する地方の好みの値であると明確に考えることができると主張するでしょう。
The refinement has cleaned up some of the policy but we still have a large number of individual policies representing the same basic provider policy "from the customer, accept customer routes". These can be simplified by using AS sets.
気品は方針のいくつかをきれいにしましたが、私たちは多くの独特の方針に同じ基本的なプロバイダー方針をまだ表させています。「顧客から、顧客ルートを受け入れてください。」 ASセットを使用することによって、これらを簡素化できます。
First, we will collect together all of AS1's customers into a single AS set, AS1:AS-CUSTOMERS. We use a hierarchical set name that start with AS1 to avoid possible set name clashes in IRR with other ASes:
まず最初に、私たちはAS1の顧客のすべてをただ一つのASセット、AS1に一緒に集めるつもりです: AS-CUSTOMERS。 私たちはAS1から他のASesとIRRでの可能なセット名前衝突を避け始める階層的なセット名を使用します:
as-set: AS1:AS-CUSTOMERS
members: AS2, AS3, AS5
資産: AS1: AS-CUSTOMERSメンバー: AS2、AS3、AS5
We also define one set for each customer which lists the AS numbers of any of their customers.
また、私たちは彼らの顧客のどれかのAS番号を記載する各顧客あたり1セットを定義します。
as-set: AS1:AS-CUSTOMERS:AS2
members: AS4
資産: AS1:AS-CUSTOMERS:AS2メンバー: AS4
as-set: AS1:AS-CUSTOMERS:AS3
members: AS4
資産: AS1:AS-CUSTOMERS:AS3メンバー: AS4
as-set: AS1:AS-CUSTOMERS:AS5
members: # AS5 has no customers yet, so keep blank for now
資産: AS1:AS-CUSTOMERS:AS5メンバー: # AS5には顧客が全くまだいないので、空白の状態で、当分保ってください。
We can now use the keyword PeerAS with these AS sets to simplify the policy further:
私たちは現在、これらのASとPeerASがさらに方針を簡素化するように設定するキーワードを使用できます:
Meyer, et al. Informational [Page 12] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[12ページ]のRFC2650
aut-num: AS1
import: {
from AS-ANY
action pref=10;
accept community.contains(1:1);
from AS-ANY
action pref=0;
accept ANY;
} refine {
from AS1:AS-CUSTOMERS
accept (PeerAS OR AS1:AS-CUSTOMER:PeerAS)
AND <^PeerAS+ AS1:AS-CUSTOMER:PeerAS*$>
}
aut-num: AS1はインポートします: いずれのAS動作pref=10から; community.contains(1:1)を受け入れてください、; いずれのAS動作pref=0から; 何でも受け入れてください;洗練される。AS1から: AS-CUSTOMERSは(PeerAS OR AS1:AS-CUSTOMER:PeerAS)と<^PeerAS+AS1:AS-CUSTOMER:PeerAS*$>を受け入れます。
The use of PeerAS with AS1:AS-CUSTOMERS is basically equivalent to looping over the members of AS1:AS-CUSTOMERS, expanding the policy by replacing PeerAS with a member from the set AS1:AS-CUSTOMERS.
AS1とのPeerASの使用: AS-CUSTOMERSは基本的にAS1: AS-CUSTOMERSのメンバーの上で輪にするのに同等です、PeerASをセットAS1からメンバーに取り替えることによって方針を広げて: AS-CUSTOMERS。
To illustrate how this policy might be utilised by AS4, we present the following policy fragment:
この方針がAS4によってどう利用されるかもしれないかを例証するために、私たちは以下の方針断片を提示します:
aut-num: AS4
export: to AS2
action community.append(1:1);
announce AS1
export: to AS3
announce AS1
aut-num: AS4はエクスポートします: AS2動作community.append(1:1)に。 AS1がエクスポートすると発表してください: AS3に、AS1を発表してください。
Here, AS4 is signalling AS1 to prefer the routes from AS3.
ここで、AS4は、AS3からルートを好むようにAS1に合図しています。
3 Tools
3つのツール
In this section, we briefly introduce a number of tools which can be used to inspect data in the database, to determine optimal routing policies, and enter new data.
このセクションでは、私たちは、最適ルーティング方針を決定して、新しいデータを入力するために、簡潔に、データベースのデータを点検するのに使用できる多くのツールを導入します。
3.1 The aut-num Object Editor
3.1 aut-num Object Editor
All the examples shown in the previous sections may well be edited by hand. They may be extracted one by one from the IRR using the whois program, edited, and then handed back to the registry robots. However, again the RAToolSet [6] provides a very nice tool which makes working with aut-num objects much easier: the aut-num object editor aoe.
前項で示されたすべての例がたぶん手で編集されるでしょう。 それらをIRRから編集されたwhoisプログラムを使用することでひとつずつ抽出して、次に、登録ロボットに返すかもしれません。 しかしながら、一方、RAToolSet[6]はaut-numオブジェクトが多く働いているのをより簡単にする非常に良いツールを提供します: aut-numオブジェクトエディタaoe。
The aut-num object editor has a graphical user interface to view and manipulate aut-num objects registered at any IRR. New aut-num objects may be generated using templates and submitted to the registries.
aut-numオブジェクトエディタには、どんなIRRにも登録されたaut-numオブジェクトを見て、操作するグラフィカルユーザーインターフェースがあります。 新しいaut-numオブジェクトをテンプレートを使用することで生成して、登録に提出するかもしれません。
Meyer, et al. Informational [Page 13] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[13ページ]のRFC2650
Moreover, the routing policy from the databases may be compared to real life peerings. Therefore, aoe is highly recommended as an interface to the IRR for aut-num objects. Further information on aoe is available together with the RAToolSet [6].
そのうえ、データベースからのルーティング方針は現実のpeeringsと比較されるかもしれません。 したがって、aoeはaut-numオブジェクトのためのIRRへのインタフェースとして非常にお勧めです。 aoeの詳細はRAToolSet[6]と共に利用可能です。
3.2 Router Configuration Using RtConfig
3.2 RtConfigを使用するルータ構成
RtConfig is a tool developed by the Routing Arbiter project [8] to generate vendor specific router configurations from the policy data held in the various IRRs. RtConfig currently supports Cisco, gated and RSd configuration formats. It has been publicly available since late 1994, and is currently being used by many sites for router configuration. The next section describes a methodology for generating vendor specific router configurations using RtConfig (2).
RtConfigは様々なIRRsに保持された方針データからベンダーの特定のルータ構成を生成するためにルート設定Arbiterプロジェクト[8]によって開発されたツールです。 RtConfigは現在、シスコ、外出を禁止されるのとRSd構成形式をサポートします。 それは、1994年後半以来公的に利用可能であり、現在、ルータ構成に多くのサイトによって使用されています。 次のセクションは、RtConfig(2)を使用することでベンダーの特定のルータ構成を生成するために方法論について説明します。
3.3 Using RtConfig
3.3 RtConfigを使用すること。
The general paradigm for using RtConfig involves registering policy in an IRR, building a RtConfig source file, then running running RtConfig against the source file and the IRR database to create vendor specific router configuration for the specified policy. The source file will contain vendor specific commands as well as RtConfig commands. To make a source file, pick up one of your router configuration files and replace the vendor specific policy configuration commands with the RtConfig commands.
RtConfigを使用するための一般的なパラダイムは、IRRの方針を登録することを伴います、RtConfigソースファイルを造って、ベンダーの特定のルータ構成を作成するためにソースファイルとIRRデータベースに対してRtConfigを実行するのがその時特約保険証券のために稼働して。 ソースファイルはRtConfigコマンドと同様にベンダーの特定のコマンドを含むでしょう。 ソースファイルを作るために、ルータ構成ファイルの1つを拾ってください、そして、ベンダー特定保険証券構成コマンドをRtConfigコマンドに取り替えてください。
Commands beginning with @RtConfig instruct RtConfig to perform special operations. An example source file is shown in Figure 11. In this example, commands such as "@RtConfig import AS3582 198.32.162.1 AS3701 198.32.162.2" instruct RtConfig to generate vendor specific import policies where the router 198.32.162.1 in AS3582 is importing routes from router 198.32.162.2 in AS3701. The other @RtConfig commands instruct the RtConfig to use certain names and numbers in the output that it generates (please refer to RtConfig manual [8] for additional information).
@RtConfigで始まるコマンドは、特殊作戦を実行するようRtConfigに命令します。 例のソースファイルは図11で見せられます。 「この例では、」 @RtConfigなどのコマンドが、AS3582 198.32.162.1 AS3701 198.32が方針にどこをインポートする0.2インチが、ベンダー詳細を生成するRtConfigに命令する.162であることを意味する、ルータ、198.32、.162、.1、AS3582でルータからルートをインポートしている、198.32、.162、.2、AS3701で。 他の@RtConfigコマンドは、それが生成する(追加情報についてRtConfigマニュアル[8]を参照してください)出力に、ある名前と数を使用するようRtConfigに命令します。
Once a source file is created, the file is processed by RtConfig (the default IRR is the RADB, and the default vendor is Cisco; however, command line options can be used to override these values). The result of running RtConfig on the source file in Figure 11 is shown in Figure 19 in Appendix B.
ソースファイルがいったん作成されると、ファイルはRtConfigによって処理されます(デフォルトベンダーはシスコです; デフォルトIRRはRADBです、そして、しかしながら、これらの値をくつがえすのにコマンドラインのオプションは使用できます)。 図11のソースファイルにRtConfigを実行するという結果はAppendix Bの図19に示されます。
Meyer, et al. Informational [Page 14] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[14ページ]のRFC2650
router bgp 3582
network 128.223.0.0
!
! Start with access-list 100
!
@RtConfig set cisco_access_list_no = 100
!
! NERO
neighbor 198.32.162.2 remote-as 3701
@RtConfig set cisco_map_name = "AS3701-EXPORT"
@RtConfig export AS3582 198.32.162.1 AS3701 198.32.162.2
@RtConfig set cisco_map_name = "AS3701-IMPORT"
@RtConfig import AS3582 198.32.162.1 AS3701 198.32.162.2
!
! WNA/VERIO
neighbor 198.32.162.6 remote-as 2914
@RtConfig set cisco_map_name = "AS2914-EXPORT"
@RtConfig export AS3582 198.32.162.1 AS2914 198.32.162.6
@RtConfig set cisco_map_name = "AS2914-IMPORT"
@RtConfig import AS3582 198.32.162.1 AS2914 198.32.162.6
bgp3582がネットワークでつなぐルータ、128.223、.0、.0、アクセスリストの@RtConfigの設定コクチマス_アクセス100!_とStartが_いいえ=100!ネロ隣人198.32.162、.2を記載する、リモートである、-、3701年の@RtConfigセットコクチマス_地図_名=の「AS3701-輸出」@RtConfigは、AS3582 198.32.162.1AS3701 198.32.162.2@RtConfigセットコクチマス_地図_名=の「AS3701-輸入」@RtConfig輸入がAS3582 198であるとエクスポートします; 32.162.1 AS3701 198.32、.162、.2、WNA/VERIO隣人198.32.162.6、リモートである、-、2914年の@RtConfigセットコクチマス_地図_名=の「AS2914-輸出」@RtConfigは、AS3582 198.32.162.1AS2914 198.32.162.6@RtConfigセットコクチマス_地図_名=の「AS2914-輸入」@RtConfigが輸入AS3582 198.32.162.1AS2914 198.32.162.6であるとエクスポートします。
Figure 11: RtConfig Template File
図11: RtConfigテンプレートファイル
Meyer, et al. Informational [Page 15] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[15ページ]のRFC2650
A RPSL Database Objects
RPSLデータベースオブジェクト
In this appendix, we introduce the RPSL objects required to implement many
typical Internet routing policies. RFC-2622 and RIPE-157 provide the
authoritative description for these objects and for the RPSL syntax, but
this appendix will often be sufficient in practice.
この付録では、私たちは目的が多くの典型的なインターネット・ルーティング政策を実施するのを必要としたRPSLを導入します。 RFC-2622とRIPE-157はこれらのオブジェクトとRPSL構文のための正式の記述を提供しますが、この付録は実際にはしばしば十分です。
The frequently needed objects are:
頻繁に必要なオブジェクトは以下の通りです。
o maintainer objects (mntner)
o 維持装置オブジェクト(mntner)
o autonomous system number objects (aut-num)
o 自律システム数のオブジェクト(aut-num)
o route objects (route)
o ルートオブジェクト(ルート)
o set objects (as-set, route-set)
o オブジェクトを設定してください。(資産、ルートセット)
and they are described in the following sections. To make your routing policies and configuration public, these objects should be registered in exactly one of the IRR registries.
そして、それらは以下のセクションで説明されます。 あなたのルーティング方針と構成を公共にするように、これらのオブジェクトはちょうどIRR登録の1つに登録されるべきです。
In general, you can register your information by sending the appropriate objects to an email address for the registry you use. The email should consist of the objects you want to have registered or modified, separated by empty lines, and preceded by some kind of authentication details (see below). The registry robot processes your mail and enters new objects into the database, deletes old ones (upon request), or makes the requested modifications.
一般に、あなたは、あなたが使用する登録のためのEメールアドレスに適切なオブジェクトを送ることによって、情報を登録できます。 メールはあなたが登録したかったか、変更して、空の系列で切り離して、またはある種の認証の詳細で先行したかったオブジェクトから成るべきです(以下を見てください)。 登録ロボットは、あなたのメールを処理して、新しいオブジェクトをデータベースに入れるか、古いもの(要求での)を削除するか、または要求された変更をします。
You will receive a response indicating the status of your submission. As the emails are handled automatically, the response is generally very fast. However, it should be remembered that a significant number of updates are also sometimes submitted to the database (by other robots), so the response time cannot be guaranteed. The email addresses for submitting objects to the existing registries are listed in Figure 12.
あなたはあなたの服従の状態を示す応答を受けるでしょう。 メールが自動的に扱われるとき、一般に、応答は非常に速いです。 しかしながら、応答時間を保証できないようにまた、時々データベース(他のロボットによる)に多くのアップデートを提出したのが覚えていられるべきです。 既存の登録にオブジェクトを提出するためのEメールアドレスは図12にリストアップされています。
ANS auto-dbm@ans.net
CANET auto-dbm@canet.net
CW auto-rr@cw.net
RADB auto-dbm@ra.net
RIPE auto-dbm@ripe.net
ANSのCANETの自動dbm@canet.net CWの auto-rr@cw.net RADB自動dbm@ra.net RIPEの auto-dbm@ans.net auto-dbm@ripe.net
Figure 12: Email addresses to register policy objects in IRR.
図12: IRRに政策目的を登録するEメールアドレス。
Meyer, et al. Informational [Page 16] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[16ページ]のRFC2650
Because it is required that a maintainer be specified in many of the database objects, a mntner is usually the first to be created. To have it properly authenticated, a mntner object is added manually by registry staff. Thereafter, all database submissions, deletions and modifications should be done through the registry robot.
維持装置がデータベースオブジェクトの多くで指定されるのが必要であるので、通常、mntnerは作成されるべき第1です。 それを適切に認証させるために、mntnerオブジェクトは登録スタッフによって手動で加えられます。 その後、すべてのデータベース差出、削除、登録ロボットを通して変更するべきです。
Each of the registries can provide additional information and support for users. For the public registries this support is available from the email addresses listed in Figure 13.
それぞれの登録はユーザの追加情報とサポートを提供できます。 公共の登録に、このサポートは図13にリストアップされたEメールアドレスから利用可能です。
RADB db-admin@ra.net
RIPE ripe-dbm@ripe.net
RADBの db-admin@ra.net のRIPEの熟しているdbm@ripe.net
Figure 13: Support email addresses.
図13: Eメールアドレスをサポートしてください。
If you are using one of the private registries, your service provider should be able to address your questions.
あなたが個人的な登録の1つを使用しているなら、あなたのサービスプロバイダーはあなたの質問を扱うことができるべきです。
A.1 The Maintainer Object
A.1維持装置オブジェクト
The maintainer object is used to introduce some kind of authorization for registrations. It lists various contact persons and describes security mechanisms that will be applied when updating objects in the IRR. Registering a mntner object is the first step in creating policies for an AS. An example is shown in Figure 14. The maintainer is called MAINT-AS3701. The contact person here is the same for administrative (admin-c) and technical (tech-c) issues and is referenced by the NIC-handle DMM65. NIC-handles are unique identifiers for persons in registries. Refer to registry documentation for further details on person objects and usage of NIC-handles.
維持装置オブジェクトは、登録証明書のためにある種の承認を導入するのに使用されます。 IRRでオブジェクトをアップデートするとき、それは、様々な連絡窓口を記載して、適用されるセキュリティー対策について説明します。 mntnerオブジェクトを登録するのは、ASのために方針を作成することにおいて第一歩です。 例は図14に示されます。 維持装置はMAINT-AS3701と呼ばれます。 ここの連絡窓口は、管理的(アドミンc)、そして、技術的な(科学技術のc)問題に同じであり、NIC-ハンドルDMM65によって参照をつけられます。 NIC-ハンドルは登録の人々にとって、ユニークな識別子です。 さらに詳しい明細についてはNIC-ハンドルの人のオブジェクトと使用法に関する登録ドキュメンテーションを参照してください。
The example shows two authentication mechanisms: CRYPT-PW and MAIL- FROM. CRYPT-PW takes as its argument a password that is encrypted with Unix crypt (3) routine. When sending updates, the maintainer adds the field password: <cleartext password> to the beginning of any requests that are to be authenticated. MAIL-FROM takes an argument that is a regular expression which covers a set of mail addresses. Only users with any of these mail addresses are authorized to work with objects secured by the corresponding maintainer (3).
例は2台の認証機構を示しています: 地下室-PWとメール CRYPT-PWは議論としてUnix地下室(3)ルーチンで暗号化されるパスワードをみなします。 アップデートを送るとき、維持装置は分野パスワードを加えます: 認証されることになっているどんな要求の始まりまでの<cleartextパスワード>。 メール-FROMは1セットの郵便の宛先をカバーする正規表現である議論を取ります。 オブジェクトが対応する維持装置(3)によって固定されている状態でこれらの郵便の宛先のどれかをもっているユーザだけが働くのに権限を与えられます。
The security mechanisms of the mntner object will only be applied on those objects referencing a specific mntner object. The reference is done by adding the attribute mnt-by to an object using the name of the mntner object as its value. In Figure 14, the maintainer MAINT- AS3701 is maintained by itself.
mntnerオブジェクトのセキュリティー対策は特定のmntnerオブジェクトに参照をつけるそれらのオブジェクトに適用されるだけでしょう。 値としてmntnerオブジェクトの名前を使用することで近く属性mntをオブジェクトに加えることによって、参照します。 図14では、維持装置MAINT- AS3701はそれ自体で維持されます。
Meyer, et al. Informational [Page 17] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[17ページ]のRFC2650
mntner: MAINT-AS3701
descr: Network for Research and Engineering in Oregon
remark: Internal Backbone
admin-c: DMM65
tech-c: DMM65
upd-to: noc@nero.net
auth: CRYPT-PW 949WK1mirBy6c
auth: MAIL-FROM .*@nero.net
notify: noc@nero.net
mnt-by: MAINT-AS3701
changed: meyer@antc.uoregon.edu 970318
source: RADB
mntner: MAINT-AS3701 descr: オレゴン注意におけるResearchとEngineeringのために以下をネットワークでつないでください。 内部のBackboneアドミンc: DMM65の科学技術のc: DMM65 upd、-、: noc@nero.net auth: CRYPT-PW 949WK1mirBy6c auth: メール-FROM .*@nero.net に通知します: 近く noc@nero.net mnt: MAINT-AS3701は変化しました: meyer@antc.uoregon.edu 970318ソース: RADB
Figure 14: Maintainer Object
図14: 維持装置オブジェクト
A.2 The Autonomous System Object
A.2自律システムオブジェクト
The autonomous system object describes the import and export policies of an AS. Each organization registers an autonomous system object (aut-num) in the IRR for its AS. Figure 15 shows the aut-num for AS3582 (UONET).
自律システムオブジェクトはASの輸出入方針を説明します。 各組織はASのために、IRRに自律システムオブジェクト(aut-num)を登録します。 図15はAS3582(UONET)のためにaut-numを示しています。
The autonomous system object lists contacts (admin-c, tech-c) and is maintained by (mnt-by) MAINT-AS3701 which is the maintainer displayed in Figure 14.
自律システムオブジェクトは、接触(アドミンc、科学技術のc)を記載して、図14に表示された維持装置である(近くmnt)MAINT-AS3701によって維持されます。
The most important attributes of the aut-num object are import and export. The import clause of an aut-num specifies import policies, while the export clause specifies export policies. The corresponding clauses allow a very detailed description of the routing policy of the AS specified. The details are given in section 2.
aut-numオブジェクトの最も重要な属性は輸出入です。 aut-numの輸入節は輸入政策を指定しますが、輸出節は輸出方針を指定します。 対応する節は指定されたASのルーティング方針の非常に詳細な記述を許容します。 詳細はセクション2に述べられます。
With these clauses, an aut-num object shows its relationship to other autonomous systems by describing its peerings. In addition, it also defines a routing entity comprising a group of IP networks which are handled according to the rules defined in the aut-num object. Therefore, it is closely linked to route objects.
これらの節で、aut-numオブジェクトは、peeringsについて説明することによって、他の自律システムとの関係を示しています。 また、さらに、それはaut-numオブジェクトで定義された規則に従って扱われるIPネットワークのグループを包括するルーティング実体を定義します。 したがって、それは、オブジェクトを発送するために密接にリンクされます。
In this example, AS3582 imports all routes from AS3701 by using the keyword ANY. AS3582 imports only internal routes from AS4222, AS5650, and AS1798. The import policy for for AS2914 is slightly more complex. Since AS2914 provides transit to various other ASes, AS3582 accepts routes with ASPATHs that begin with AS2194 followed by members of AS-WNA, which is an as set (see section A.4.1 below) describing those customers that transit AS2914.
この例では、AS3582は、AS3701から少しもキーワードを使用することによって、すべてのルートをインポートします。 AS3582はAS4222、AS5650、およびAS1798から内部のルートだけをインポートします。 方針をインポートする、AS2914がわずかに複雑であるので。 AS2914が他の様々なASesにトランジットを供給するのでAS3582がAS2194がAS-WNAのメンバーによって後をつけられている状態で始まって、そうするASPATHsがあるルートを受け入れる、それらの顧客のためにそのトランジットAS2914について説明しながらセットするように(以下のセクションA.4.1を見ます)。
Meyer, et al. Informational [Page 18] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[18ページ]のRFC2650
Since AS3582 is a multi-homed stub AS (i.e., it does not provide transit), its export policy consists simply of "announce AS3582" clauses; that is, announce internal routes of AS3582. These routes are those in route objects where the origin attribute is AS3582.
以来AS3582がaである、マルチ、家へ帰り、スタッブAS(すなわち、それはトランジットを提供しない)、輸出方針は単に「AS3582を発表してください」という節から成ります。 すなわち、AS3582の内部のルートを発表してください。 これらのルートは発生源属性がAS3582であるルートオブジェクトのそれらです。
aut-num: AS3582
as-name: UONET
descr: University of Oregon, Eugene OR
import: from AS3701 accept ANY
import: from AS4222 accept <^AS4222+$>
import: from AS5650 accept <^AS5650+$>
import: from AS2914 accept <^AS2914+ (AS-WNA)*$>
import: from AS1798 accept <^AS1798+$>
export: to AS3701 announce AS3582
export: to AS4222 announce AS3582
export: to AS5650 announce AS3582
export: to AS2914 announce AS3582
export: to AS1798 announce AS3582
admin-c: DMM65
tech-c: DMM65
notify: nethelp@ns.uoregon.edu
mnt-by: MAINT-AS3582
changed: meyer@antc.uoregon.edu 970316
source: RADB
aut-num: AS3582、名前として: UONET descr: オレゴン大学、ユージンOR輸入: AS3701から、あらゆる輸入を受け入れてください: AS4222から、<^AS4222+$>輸入を受け入れてください: AS5650から、<^AS5650+$>輸入を受け入れてください: AS2914から、<^AS2914+(AS-WNA)*$>輸入を受け入れてください: AS1798から、<^AS1798+$>輸出を受け入れてください: AS3701に、AS3582がエクスポートすると発表してください: AS4222に、AS3582がエクスポートすると発表してください: AS5650に、AS3582がエクスポートすると発表してください: AS2914に、AS3582がエクスポートすると発表してください: AS1798に、AS3582アドミンcを発表してください: DMM65の科学技術のc: DMM65は通知します: 近く nethelp@ns.uoregon.edu mnt: MAINT-AS3582は変化しました: meyer@antc.uoregon.edu 970316ソース: RADB
Figure 15: Autonomous System Object
図15: 自律システムオブジェクト
The aut-num object forms the basis of a scalable and maintainable router
aut-numオブジェクトはスケーラブルで維持できるルータの基礎を形成します。
route: 128.223.0.0/16
origin: AS3582
descr: UONet
descr: University of Oregon
descr: Computing Center
descr: Eugene, OR 97403-1212
descr: USA
mnt-by: MAINT-AS3582
changed: meyer@ns.uoregon.edu 960222
source: RADB
以下を発送してください。 128.223.0.0/16発生源: AS3582 descr: UONet descr: オレゴン大学descr: コンピューティングセンターdescr: ユージン、OR97403-1212descr: 近く米国mnt: MAINT-AS3582は変化しました: meyer@ns.uoregon.edu 960222ソース: RADB
Figure 16: Example of a route object
図16: ルートオブジェクトに関する例
configuration system. For example, if AS3582 originates a new route, it need only create a route object for that route with origin AS3582. AS3582 can now build configuration using this route object without changing its aut-num object.
コンフィギュレーションシステム。 例えば、AS3582が新しいルートを溯源するなら、それは発生源AS3582と共にルートオブジェクトをそのルートに作成するだけでよいです。 AS3582は、現在、aut-numオブジェクトを変えないでこのルートオブジェクトを使用することで構成を築き上げることができます。
Meyer, et al. Informational [Page 19] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[19ページ]のRFC2650
Similarly, if for example, AS3701 originates a new route, it need only create a route object for that route with origin AS3701. Both AS3701 and AS3582 can now build configuration using this route object without modifying its aut-num object.
同様に、例えば、AS3701が新しいルートを溯源するなら、それは発生源AS3701と共にルートオブジェクトをそのルートに作成するだけでよいです。 AS3701とAS3582の両方が、現在、aut-numオブジェクトを変更しないでこのルートオブジェクトを使用することで構成を築き上げることができます。
A.3 The Route Object
A.3ルートオブジェクト
In contrast to aut-num objects which describe propagation of routing information for an autonomous system as a whole, route objects define single routes from an AS. An example is given in Figure 16.
全体で自律システムのためのルーティング情報の伝播について説明するaut-numオブジェクトと対照して、ルートオブジェクトはASからただ一つのルートを定義します。 例は図16で出されます。
This route object is maintained by MAINT-AS3582 and references AS3582 by the origin attribute. By this reference it is grouped together with other routes of the same origin AS, becoming member of the routing entity denoted by AS3582. The routing policies can then be defined in the aut-num objects for this group of routes.
このルートオブジェクトは発生源属性によってMAINT-AS3582と参照AS3582によって維持されます。 この参照で、それは同じ発生源ASの他のルートと共に分類されます、AS3582によって指示されたルーティング実体のメンバーになって。 そして、ルートのこのグループのためにaut-numオブジェクトでルーティング方針を定義できます。
Consequently, the route objects give the routes from this AS which are distributed to peer ASes according to the rules of the routing policy. Therefore, for any route in the routing tables of the backbone routers a route object must exist in one of the registries in IRR. route objects must be registered in the IRR only for the routes seen outside your AS. Normally, this set of external routes is different from the routes internally visible within your AS. One of the major reasons is that external peers need no information at all about your internal routing specifics. Therefore, external routes are in general aggregated combinations of internal routes, having shorter IP prefixes where applicable according to the CIDR rules. Please see the CIDR FAQ [5] for a tutorial introduction to CIDR. It is strongly recommended that you aggregate your routes as much as possible, thereby minimizing the number of routes you inject into the global routing table and at the same time reducing the corresponding number of route objects in the IRR.
その結果、ルーティング方針の規則に従って、ルートオブジェクトはこの分配されたASから同輩ASesまで進発令を下します。 したがって、バックボーンルータの経路指定テーブルのどんなルートにも、ルートオブジェクトはIRRでの登録の1つに存在しなければなりません。IRRにあなたのASの外で見られたルートだけにルートオブジェクトを登録しなければなりません。 通常、このセットの外部経路はあなたのASの中で内部的に目に見えるルートと異なっています。 主要な理由の1つは外部の同輩があなたの内部のルーティング詳細に関して情報を全く必要としないということです。 したがって、外部経路は内部のルートの一般に、集められた組み合わせです、CIDR規則に従って適切であるところにより短いIP接頭語を持っていて。 個人指導用の序論に関してCIDRにおいてCIDR FAQ[5]を見てください。あなたがルートにできるだけ集めるのが強く推薦されます、その結果、あなたがグローバルな経路指定テーブルを注ぐルートの数を最小にして、同時にIRRのルートオブジェクトの対応する数を減少させて。
While you may easily query single route objects using the whois program, and submit objects via mail to the registry robots, this becomes kind of awkward for larger sets. The RAToolSet [6] offers several tools to make handling of route objects easier. If you want to read policy data from the IRR and process it by other programs, you might be interested in using peval which is a low level policy evaluation tool. As an example, the command
あなたは、whoisプログラムを使用することで容易に単一のルートオブジェクトについて質問して、登録ロボットへのメールでオブジェクトを提出できますが、これは、より大きいセットにちょっと無器用になります。 RAToolSet[6]は、ルートオブジェクトの取り扱いをより簡単にするようにいくつかのツールを提供します。 IRRから方針データを読んで、他のプログラムでそれを処理したいなら、あなたは低い平らな政策評価ツールであるpevalを使用したがっているかもしれません。 例、コマンドとして
peval -h whois.ra.net AS3582
peval-h whois.ra.net AS3582
will give you all route objects from AS3582 registered with RADB.
すべてのルートオブジェクトをRADBに登録されたAS3582からあなたに与えるでしょう。
Meyer, et al. Informational [Page 20] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[20ページ]のRFC2650
A much more sophisticated tool from the RAToolSet to handle route objects interactively is the route object editor roe. It has a graphical user interface to view and manipulate route objects registered at any IRR. New route objects may be generated from templates and submitted to the registries. Moreover, the route objects from the databases may be compared to real life routes. Therefore, roe is highly recommended as an interface to the IRR for route objects. Further information on peval and roe is available together with the RAToolSet [6].
インタラクティブにルートオブジェクトを扱うRAToolSetからのはるかに洗練されたツールはルートオブジェクトエディタ魚卵です。 それには、どんなIRRにも登録されたルートオブジェクトを見て、操作するグラフィカルユーザーインターフェースがあります。 新しいルートオブジェクトをテンプレートから生成して、登録に提出するかもしれません。 そのうえ、データベースからのルートオブジェクトは現実のルートと比較されるかもしれません。 したがって、魚卵はルートオブジェクトのためのIRRへのインタフェースとして非常にお勧めです。 pevalと魚卵の詳細はRAToolSet[6]と共に利用可能です。
A.4 Set Objects
A.4はオブジェクトを設定します。
With routing policies it is often necessary to reference groups of autonomous systems or routes which have identical properties regarding a specific policy. To make working with such groups easier RPSL allows to combine them in set objects. There are two basic types of predefined set objects, as-set, and route-set. The RPSL set objects are described below.
ルーティング方針で、それが特定保険証券に関する同じ特性を持っている自律システムかルートのレファレンス・グループにしばしば必要です。 より簡単なRPSLが中のそのようなグループをそれらを結合させている働きを作るには、オブジェクトを設定してください。 2人の基本型の事前に定義されたセットオブジェクト、資産、およびルートセットがあります。 RPSLセットオブジェクトは以下で説明されます。
A.4.1 AS-SET Object
A.4.1資産オブジェクト
Autonomous system set objects (as-set) are used to group autonomous system objects into named sets. An as-set has an RPSL name that starts with "AS-". In the example in Figure 17, an as-set called AS-NERO-PARTNERS and containing AS3701, AS4201, AS3582, AS4222, AS1798 is defined. The as-set is the RPSL replacement for the RIPE- 181 as-macro. It has been extended to include ASes in the set indirectly by referencing as set names in the aut-num objects.
自律システムセットオブジェクト(資産)は、自律システムオブジェクトを命名されたセットに分類するのに使用されます。 資産にはそれが始まるRPSL名がある、「-、」 図17の例では、資産は、ASネロPARTNERSと呼びました、そして、AS3701、AS4201、AS3582、AS4222を含んでいて、AS1798は定義されます。 資産はマクロとしてRIPE181へのRPSL交換です。 セットに間接的にセット名としてaut-numでオブジェクトに参照をつけることによってASesを含むようにそれを広げてあります。
AS-SETs are particularly useful when specifying policies for groups such as customers, providers, or for transit. You are encouraged to register sets for these groups because it is most likely that you will treat them alike, i.e. you will have a very similar routing policy for all your customers which have an autonomous system of their own. You may as well discover that this is also true for the providers you are peering with, and it is most convenient to have the ASes combined in one as-set for which you offer transit. For example, if a transit provider specifies its import policy using its customer's as-set (i.e., its import clause for the customer contains the customer's as-set), then that customer can modify the set of ASes that its transit provider accepts from it. Again, this can be accomplished without requiring the customer or the transit provider to modify its aut-num object.
顧客、プロバイダーなどのグループかトランジットのための方針を指定するとき、AS-SETsは特に役に立ちます。 あなたが同じくそれらを扱って、すなわち、あなたのすべての顧客のための非常に同様のルーティング方針があるのが、たぶんであるのであなたがこれらのグループのためにセットを登録するよう奨励されます(それら自身の自律システムを持っています)。 あなたは、また、あなたがじっと見ているプロバイダーに、これも本当であると発見するほうがよいです、そして、あなたがトランジットを提供する1つの資産にASesを結合させるのは最も便利です。 例えば、トランジットプロバイダーが顧客の資産を使用することで輸入政策を指定するなら(すなわち、顧客への輸入節は顧客の資産を含んでいます)、その顧客はトランジットプロバイダーがそれから受け入れるASesのセットを変更できます。 一方、aut-numオブジェクトを変更するために顧客かトランジットプロバイダーを必要としないで、これを達成できます。
as-set: AS3582:AS-PARTNERS
members: AS3701, AS4201, AS3582, AS4222, AS1798
資産: AS3582: AS-PARTNERSメンバー: AS3701、AS4201、AS3582、AS4222、AS1798
Figure 17: as-set Object
図17: 資産Object
Meyer, et al. Informational [Page 21] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[21ページ]のRFC2650
The ASes of the set are simply compiled in a comma delimited list following the members attribute of the as-set. This list may also contain other AS-SET names.
資産のメンバー属性に続いて、セットのASesはコンマの区切られたリストで単にコンパイルされます。 また、このリストは他のAS-SET名を含むかもしれません。
A.4.2 ROUTE-SET Object
A.4.2ルートセットオブジェクト
A route-set is a way to name a group of routes. The syntax is similar to the as-set. A route-set has an RPSL name that starts with "RS-". The members attribute lists the members of the set. The value of a members attribute is a list of address prefixes, or route-set names. The members of the route-set are the address prefixes or the names of other route sets specified.
ルートセットはルートのグループを命名する方法です。 構文は資産と同様です。 ルートセットに、「RS」から始まるRPSL名があります。 メンバー属性はセットのメンバーを記載します。 メンバー属性の値はアドレス接頭語、またはルートセット名のリストです。 ルートセットのメンバーはアドレス接頭語であるか他のルートセットの名前が指定しました。
Figure 18 presents some example route-set objects. The set rs-uo contains two address prefixes, namely 128.223.0.0/16 and 198.32.162.0/24. The set rs-bar contains the members of the set rs- uo and the address prefix 128.7.0.0/16. The set rs-martians illustrate the use of range operators. 0.0.0.0/0^32 are the length 32 more specifics of 0.0.0.0/0, i.e. the host routes; 224.0.0.0/3^+ are the more specifics of 224.0.0.0/3, i.e. the routes falling into the multicast address space. For more complete list of range operators please refer to RFC-2622.
図18はいくつかの例のルートセットオブジェクトを贈ります。 セットrs-uoは.0/24に2つのアドレス接頭語、すなわち、128.223.0 16と.0/198.32.162を含んでいます。 セットrs-弁護士会はセットrs- uoとアドレス接頭語128.7.0.0/16のもののメンバーを含みます。 セットrs-martiansは範囲のオペレータの使用を例証します。 0.0.0.0/0^32が長さもう32の詳細である、0.0 .0 すなわち、.0/0、ホストルート。 224.0.0.0/3^+は224.0の、より多くの詳細です。.0 すなわち、.0/3、マルチキャストアドレス空間になるルート。 範囲のオペレータの、より多くの全リストについて、RFC-2622を参照してください。
route-set: rs-uo
members: 128.223.0.0/16, 198.32.162.0/24
ルートセット: rs-uoメンバー: 128.223.0.0/16, 198.32.162.0/24
route-set: rs-bar
members: 128.7.0.0/16, rs-uo
ルートセット: rs-バーメンバー: 128.7.0.0/16、rs-uo
route-set: rs-martians
remarks: routes not accepted from any peer
members: 0.0.0.0/0, # default route
0.0.0.0/0^32, # host routes
224.0.0.0/3^+, # multicast routes
127.0.0.0/8^9-32, . . .
ルートセット: rs-martians所見: ルートはどんな同輩メンバーからも受け入れませんでした: 0.0.0.0/0、#デフォルトが0.0.0.0/0^32を発送して、#ホストルート224.0が.0.0/3^+であり、#マルチキャストルートは127.0.0.0/8^9-32です…
Figure 18: route-set Objects
図18: ルートセットObjects
Meyer, et al. Informational [Page 22] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[22ページ]のRFC2650
B Output of RtConfig: An Example
RtConfigのB出力: 例
In Figure 19, you see the result of running RtConfig on the source
file in Figure 11.
あなたは図11のソースファイルにRtConfigを実行するという図19の、結果を見ます。
router bgp 3582
network 128.223.0.0
!
! NERO
neighbor 198.32.162.2 remote-as 3701
ルータbgp3582年のネットワーク128.223.0.0!ネロ隣人198.32.162.2、リモートである、-、3701
no access-list 100
access-list 100 permit ip 128.223.0.0 0.0.0.0 255.255.0.0 0.0.0.0
access-list 100 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
!
no route-map AS3701-EXPORT
route-map AS3701-EXPORT permit 1
match ip address 100
!
router bgp 3582
neighbor 198.32.162.2 route-map AS3701-EXPORT out
!
no route-map AS3701-IMPORT
route-map AS3701-IMPORT permit 1
set local-preference 1000
!
router bgp 3582
neighbor 198.32.162.2 route-map AS3701-IMPORT in
!
! WNA/VERIO
neighbor 198.32.162.6 remote-as 2914
!
no route-map AS2914-EXPORT
route-map AS2914-EXPORT permit 1
match ip address 100
!
router bgp 3582
neighbor 198.32.162.6 route-map AS2914-EXPORT out
no ip as-path access-list 100
ip as-path access-list 100 permit ^_2914(((_[0-9]+))*_ \
(13|22|97|132|175|668|1914|2905|2914|3361|3381|3791|3937| \
4178|4354|4571|4674|4683|5091|5303|5798|5855|5856|5881|6083 \
|6188|6971|7790|7951|8028))?$
!
no route-map AS2914-IMPORT
route-map AS2914-IMPORT permit 1
match as-path 100
set local-preference 998
no access-list 100 access-list 100 permit ip 128.223.0.0 0.0.0.0 255.255.0.0 0.0.0.0 access-list 100 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 ! no route-map AS3701-EXPORT route-map AS3701-EXPORT permit 1 match ip address 100 ! router bgp 3582 neighbor 198.32.162.2 route-map AS3701-EXPORT out ! no route-map AS3701-IMPORT route-map AS3701-IMPORT permit 1 set local-preference 1000 ! router bgp 3582 neighbor 198.32.162.2 route-map AS3701-IMPORT in ! ! WNA/VERIO neighbor 198.32.162.6 remote-as 2914 ! no route-map AS2914-EXPORT route-map AS2914-EXPORT permit 1 match ip address 100 ! router bgp 3582 neighbor 198.32.162.6 route-map AS2914-EXPORT out no ip as-path access-list 100 ip as-path access-list 100 permit ^_2914(((_[0-9]+))*_ \ (13|22|97|132|175|668|1914|2905|2914|3361|3381|3791|3937| \ 4178|4354|4571|4674|4683|5091|5303|5798|5855|5856|5881|6083 \ |6188|6971|7790|7951|8028))?$ ! no route-map AS2914-IMPORT route-map AS2914-IMPORT permit 1 match as-path 100 set local-preference 998
Meyer, et al. Informational [Page 23] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[23ページ]のRFC2650
!
router bgp 3582
neighbor 198.32.162.6 route-map AS2914-IMPORT in
中の3582年のルータbgp隣人198.32.162.6路線図AS2914-IMPORT
Figure 19: Output of RtConfig
図19: RtConfigの出力
Security Considerations
セキュリティ問題
This document is a tutorial to RPSL, it does not define protocols or
standards that need to be secured.
このドキュメントがRPSLへのチュートリアルである、それは安全にされる必要があるプロトコルか規格を定義しません。
Endnotes
エンドノート
(1) AS-PATH regular expressions are POSIX compliant regular
expressions.
(1) AS-PATH正規表現はPOSIX対応することの正規表現です。
(2) Discussion of RtConfig internals is beyond the scope of this
document.
(2) RtConfigインターナルの議論はこのドキュメントの範囲を超えています。
(3) Clearly, neither of these mechanisms is sufficient to provide
strong authentication or authorization. Other public key (e.g.,
PGP) authentication mechanisms are available from some of the
IRRs.
(3) 明確に、これらのメカニズムのどちらも、強い認証か認可を提供するために十分ではありません。 他の公開鍵(例えば、PGP)認証機構はいくつかのIRRsから利用可能です。
References
参照
[1] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer,
D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing Policy
Specification Language (RPSL)", RFC 2622, June 1999.
[1]AlaettinogluとC.とVillamizarとC.とGerichとE.とKessensとD.とマイヤーとD.とベイツとT.とKarrenbergとD.とM.テルプストラ、「ルート設定方針仕様言語(RPSL)」、RFC2622、1999年6月。
[2] Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P. and M.
Terpstra, "Representation of IP Routing Policies in the RIPE
database", Technical Report ripe-81, RIPE, RIPE NCC, Amsterdam,
Netherlands, February 1993.
[2] ベイツとT.とJouanigotとJ-M.とKarrenbergとD.とLothbergとP.とM.テルプストラ、「RIPEデータベースにおける、IPルート設定Policiesの表現」、Technical Reportの熟している81、RIPE(RIPE NCC、アムステルダム(オランダ)1993年2月)。
[3] T. Bates, E. Gerich, J. Joncharay, J-M. Jouanigot, D. Karrenberg,
M. Terpstra, and J. Yu. Representation of IP Routing Policies in
a Routing Registry, Technical Report ripe-181, RIPE, RIPE NCC,
Amsterdam, Netherlands, October 1994.
[3] T.ベイツ、E.Gerich、J.Joncharay、J-M。 Jouanigot、D.Karrenberg、M.テルプストラ、およびJ.ユー。 RIPE、RIPE NCC、アムステルダムオランダ1994年10月のルート設定Registry、Technical Reportの熟している181における、IPルート設定Policiesの表現。
[4] A. M. R. Magee. RIPE NCC Database Documentation. Technical Report
RIPE-157, RIPE NCC, Amsterdam, Netherlands, May 1997.
[4] A.M.R.マギー。 熟しているNCCデータベースドキュメンテーション。 技術報告書の熟している157の、そして、熟しているNCC、アムステルダム、オランダは1997がそうするかもしれません。
[5] Hank Nussbacher. The CIDR FAQ. Tel Aviv University and IBM
Israel. http://www.ibm.net.il/~hank/cidr.html
[5] ハンクNussbacher。 CIDR FAQ。 テルアビブ大学とIBMイスラエル http://www.ibm.net.il/~hank/cidr.html
[6] The RAToolSet. http://www.ra.net/ra/RAToolSet/
[6] RAToolSet、 http://www.ra.net/ra/RAToolSet/
Meyer, et al. Informational [Page 24] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[24ページ]のRFC2650
[7] Rekhter Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC
1654, July 1994.
[7]Rekhter Y.とT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1654 1994年7月。
[8] RtConfig as part of the RAToolSet.
http://www.ra.net/ra/RAToolSet/RtConfig.html
[8] RAToolSetの一部としてのRtConfig、 http://www.ra.net/ra/RAToolSet/RtConfig.html
[9] Chen, E. and T. Bates, "An Application of the BGP Community
Attribute in Multi-Home Routing", RFC 1998, August 1996.
[9] チェンとE.とT.ベイツ、「マルチホームルート設定における、BGP共同体属性の適用」、RFC1998、1996年8月。
Authors' Addresses
作者のアドレス
David Meyer Cisco Systems
デヴィッドマイヤーシスコシステムズ
EMail: dmm@cisco.com
メール: dmm@cisco.com
Joachim Schmitz America On-Line
オンラインヨアヒム・シュミッツ・アメリカ
EMail: SchmitzJo@aol.com
メール: SchmitzJo@aol.com
Carol Orange RIPE NCC
キャロルOrangeの熟しているNCC
EMail: orange@spiritone.com
メール: orange@spiritone.com
Mark Prior connect.com.au pty ltd
マーク・プライアーconnect.com.au pty ltd
EMail: mrp@connect.com.au
メール: mrp@connect.com.au
Cengiz Alaettinoglu USC/Information Sciences Institute
Cengiz Alaettinoglu USC/情報科学研究所
EMail: cengiz@isi.edu
メール: cengiz@isi.edu
Meyer, et al. Informational [Page 25] RFC 2650 Using RPSL in Practice August 1999
マイヤー、他 1999年8月に実際にはRPSLを使用する情報[25ページ]のRFC2650
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Meyer, et al. Informational [Page 26]
マイヤー、他 情報[26ページ]
一覧
スポンサーリンク
