RFC2519 日本語訳
2519 A Framework for Inter-Domain Route Aggregation. E. Chen, J.Stewart. February 1999. (Format: TXT=25394 bytes) (Status: INFORMATIONAL)
RFC一覧
英語原文
Network Working Group E. Chen
Request for Comments: 2519 Cisco
Category: Informational J. Stewart
Juniper
February 1999
A Framework for Inter-Domain Route Aggregation
ドメイン間における経路集約の枠組
Status of this Memo
このメモの位置づけ
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
このメモは、Internet community のための情報を提供する。これは、いか
なる種類の Internet 標準を明細に述べるものではない。このメモの配布は
無制限である。
-----------------------------------------------------------------------
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
-----------------------------------------------------------------------
Abstract
要約
This document presents a framework for inter-domain route aggregation
and shows an example router configuration which 'implements' this
framework. This framework is flexible and scales well as it
emphasizes the philosophy of aggregation by the source, both within
routing domains as well as towards upstream providers, and it also
strongly encourages the use of the 'no-export' BGP community to
balance the provider-subscriber need for more granular routing
information with the Internet's need for scalable inter-domain
routing.
この文書は、ドメイン間経路集約のための枠組を紹介し、この枠組を
'implements (実装)' したルータ設定例を示す。この枠組は、十分に柔軟で
かつ規模を大きくすることができ、同様に、上流プロバイダだけでなくルー
ティングドメイン内の両方における、始点による経路集約の考え方を強調す
る。そして、より粒度のある経路情報に関するプロバイダ加入者の必要性と
規模が大きいドメイン間ルーティングに関する the Internet の必要性のバ
ランスを保つため、'no-export' BGP コミュニティの使用も奨励する。
-----------------------------------------------------------------------
1. Introduction
1. 序論
The need for route aggregation has long been recognized. Route
aggregation is good as it reduces the size, and slows the growth, of
the Internet routing table. Thus, the amount of resources (e.g., CPU
and memory) required to process routing information is reduced and
route calculation is sped up. Another benefit of route aggregation
is that route flaps are limited in number, frequency and scope, which
saves resources and makes the global Internet routing system more
stable.
経路集約の必要性は、長い間、認識されていた。経路集約は、the Internet
経路表の大きさを減らし、成長をゆっくりするのによい。したがい、経路情
報を処理するのに必要とされるリソース (たとえば CPU とメモリ) 量は減
少し、経路計算は速くなる。経路集約における別の恩恵は、ルートフラップ
が総数、頻度と範囲について制限されることである。このことは、リソース
を残しておき、グローバルな the Internet ルーティングシステムをより安
定にする。
Since CIDR (Classless Inter-Domain Routing) [2] was introduced,
significant progress has been made on route aggregation, particularly
in the following two areas:
CIDR (Classless Inter-Domain Routing) [2] が導入されたので、重要な発
展は経路集約になっている。これは、特に次のエリアについてである:
- Formulation and implementation of IP address allocation policies
by the top registries that conform to the CIDR principles [1].
This policy work is the cornerstone which makes efficient route
aggregation technically possible.
CIDR 方針 [1] に従ったトップレジストリによる IP アドレス割り当
てポリシーの明確化と実行。このポリシー研究は、効率的な経路集約
を技術的に可能にする基礎である。
- Route aggregation by large (especially "Tier 1") providers. To
date, the largest reductions in the size of the routing table
have resulted from efficient aggregation by large providers.
大規模 (特に "Tier 1") プロバイダによる経路集約。今までのところ
ルーティングテーブルサイズの最大の削減は、大規模プロバイダによ
る効率的な集約から生じることとなった。
However, the ability of various levels of the global routing system
to implement efficient aggregation schemes varies widely. As a
result, the size and growth rate of the Internet routing table, as
well as the associated route computation required, remain major
issues today. To support Internet growth, it is important to
maximize the efficiency of aggregation at all levels in the routing
system.
しかしながら、効率的な集約計画を実行するためグローバルルーティングシ
ステムのさまざまなレベルからなる能力は、広範囲にわたり異なる。結果と
して、the Internet ルーティングテーブルのサイズと成長速度、同様にそ
れに関連される要求経路計算は、今日、主要問題のままである。Internet
成長をサポートするため、ルーティングシステムのすべてのレベルで、集約
効率を最大化にすることは重要である。
Because of the current size of the routing system and its dynamic
nature, the first step towards this goal is to establish a clearly
defined framework in which scaleable inter-domain route aggregation
can be realized. The framework described in this document is based
on the predominant and current experience in the Internet. It
emphasizes the philosophy of aggregation by the source, both within
routing domains as well as towards upstream providers. The framework
also strongly encourages the use of the "no-export" BGP community to
balance the providersubscriber need for more granular routing
information with the Internet's need for scalable inter-domain
routing. The advantages of this framework include the following:
ルーティングシステムの現在のサイズとその動的な性質のため、この目的の
最初のステップは、スケーラブルなドメイン間経路集約が実現されるよう、
定義される枠組をはっきりと確立することである。この文書で記述される枠
組は、the Internet での広くおこなわれていることと、現在の経験に基づ
く。これは、ルーティングドメイン内と、同様に上流プロバイダへの両方に
よる、始点での集約哲学を強調する。この枠組は、"no-export" BGP コミュ
ニティの使用も強く奨励する。理由は、より粒度のあるルーティング情報の
ためのプロバイダ加入者の必要性と、スケーラブルなドメイン間ルーティン
グのための the Internet の必要性とのバランスを取るためである。この枠
組の長所は、次に述べるものを含む:
- Route aggregation is done in a distributed fashion, with
emphasis on aggregation by the party or parties injecting the
aggregatable routing information into the global mesh.
経路集約は、集約可能ルーティング情報をグローバルメッシュに注入
しているパーティ、または複数パーティによる集約の強調を持つ、配
布方法でおこなわれる。
- The flexibility of a routing domain to be able to inject more
granular routing information to an adjacent domain to control
the resulting traffic patterns, without having an impact on the
global routing system.
グローバルルーティングシステム上での影響を与えることなしに、結
果トラフィックパターンを制御するため、より粒度のあるルーティン
グ情報を隣接ドメインへと注入できるようにするためのルーティング
ドメインの柔軟性。
In addition to describing the philosophy, we illustrate it by
presenting sample configurations. IPv4 prefixes, BGP4 and ASs
are used in examples, though the principles are applicable to
inter-domain route aggregation in general.
哲学の記述に加えて、われわれは、サンプルコンフィギュレーション
を示すことにより、このことを説明する。原則はドメイン間経路集約
へと一般に利用可能であるけれども、IPv4 プレフィックス(s)、BGP4
と AS(s) が例で使用される。
Address allocation policies and technologies to renumber entire
networks, while very relevant to the realization of successful
and sustained inter-domain routing, are not the focus of this
document. The references section contains pointers to relevant
documents [8, 9, 11, 12].
全体のネットワークのアドレスを再割り当てるためのアドレス割り当
てポリシーとテクニック、その上、大変関連ある成功の認識と維持さ
れるドメイン間ルーティングは、この文書の焦点ではない。参考文献
section は、関連する文書 [8, 9, 11, 12] へのポインタを含む。
-----------------------------------------------------------------------
2. Route Aggregation Framework
2. 経路集約枠組
The framework of inter-domain route aggregation we are proposing can
be summarized as follows:
われわれが提案しているドメイン間経路集約の枠組は、次のように要約され
る:
- Aggregation from the originating AS
生成 AS からの集約
That is, in its outbound route announcements, each AS aggregates
the BGP routes originated by itself, by dedicated AS and by
private-ASs [10]. ("Routes originated by an AS" refers to
routes which have that AS first in the AS path attribute. For
example, routes statically configured and injected into BGP fall
into this category.)
すなわち、外向き経路広告に、それぞれの AS は、自分自身、専用 AS
とプライベート AS(s) [10] により生成された BGP 経路を集約する。
("Routes originated by an AS" は、AS パス属性で最初の AS を持つ
経路を参照する。例えば、静的に設定されて BGP へと注入される経路
は、この分類に入る。)
This framework does not depend on "proxy aggregation" which
refers to route aggregation done by an AS other than the
originating AS. This preserves the capability of a multi-homed
site to control the granularity of routing information injected
into the global routing system. Since proxy aggregation involves
coordination among multiple organizations, the complexity of
doing proxy aggregation increases with the number of parties
involved in the coordination. The complexity, in turn, impacts
the practicality of proxy aggregation.
この枠組は、生成する AS 以外である AS によりおこなわれる経路集
約ということを参照する "proxy aggregation" に依存しない。これは
マルチホームされたサイトの能力を保つことであり、その能力とは、
グローバルルーティングシステムへと注入されているルーティング情
報の粒度を制御することである。proxy aggregation は複数組織間の
協調関係を必然的に含むので、proxy aggregation 実行の複雑さは、
協調関係に含まれるパーティ数で増える。
An AS shall always originate via a stable mechanism (e.g.,
static route configuration) the BGP routes for the large
aggregates from which it allocates addresses to customers. This
ensures that it is safe for its customers to use BGP "no-
export".
AS は、安定したメカニズム (たとえば、静的経路設定) により、大規
模な集約 (経路) について BGP 経路をいつも生成するだろう。その集
約 (経路) は、その経路から customer(s) へとアドレスを割り当てる
ためのものである。これは、その customer(s) は BGP "no-export"
を使用することが安全である、ということを保証する。
- Using BGP community "no-export" toward upstream providers
上流プロバイダに対する BGP コミュニティ "no-export" の使用
That is, in its route announcements toward its upstream
provider, an AS tags the BGP community "no-export" to routes it
originates that do not need to be propagated beyond its upstream
provider (e.g., prefixes allocated by the upstream provider).
すなわち、その上流プロバイダへの経路広告に、AS は、自分自身が生
成した経路に BGP コミュニティ "no-export" をタグづける。この生
成経路は、その上流プロバイダを越えて伝達される必要がない (たと
えば、上流プロバイダにより割り当てられたプレフィックスについて
である)。
This framework is illustrated in Figure 1. A "Tier 1" provider does
not use "no-export" in its announcement as it does not have an
upstream provider. However, it shall aggregate the routes it
originates in its outbound announcements towards both peer providers
and customers. An AS with an upstream provider shall aggregate the
routes it originates and use "no-export" toward its upstream provider
for routes that do not need to be propagated beyond its provider's
AS. This recursion shall apply to all levels of the routing
hierarchy.
この枠組は、Figure 1 で説明される。"Tier 1" プロバイダは、上流プロバ
イダを持たないとして、その広告に "no-export" を使用しない。しかしな
がら、そのプロバイダは、ピアプロバイダと customer(s) 両方への外向き
広告に、生成した経路を集約すべきである。上流プロバイダを持つ AS は、
生成する経路を集約し、プロバイダ AS を越えて伝達される必要がない経路
について、その AS へと "no-export" を使用すべきである。この反復は、
ルーティング階層の全レベルに適用されるべきである。
Tier 1
+-- Provider <--+
| |
o aggregates routes | | o announces customer routes
it originates | | o aggregates routes it originates
| ^ o uses "no-export" if appropriate
|
+---> Tier 2 <--+
Provider |
V |
| |
o aggregates routes | | o announces customer routes
it originates | | o aggregates routes it originates
| | o uses "no-export" if appropriate
| |
| ^
-> Customer AS
Figure 1
Tier 1
+--プロバイダ<--+
| |
o 生成した経路を | | o customer 経路を広告
集約 | | o 生成した経路を集約
| ^ o 適切なら "no-export" を使用
|
+---> Tier 2 <--+
プロバイダ |
V |
| |
o 生成した経路を | | o customer 経路を広告
集約 | | o 生成した経路を集約
| | o 適切なら "no-export" を使用
| |
| ^
-> Customer AS
図 1
This framework scales well as aggregation is done at all levels of
the routing system. It is flexible because the originating AS
controls whether routes of finer granularity are injected to, and/or
propagated by, its upstream provider. It facilitates multi-homing
without compromising route aggregation.
集約と同様に、この枠組スケールは、ルーティングシステムの全レベルでお
こなわれる。生成している AS は、よりよい粒度のある経路が、その上位プ
ロバイダへと注入される、and/or その上位プロバイダにより伝達されるか
どうかを制御するので、このことは柔軟である。これは、妥協する経路集約
なしにマルチホーム化を容易にする。
This framework is detailed in the following sections.
この枠組は、次の section(s) で詳しく述べる。
-----------------------------------------------------------------------
3. Aggregation from the Originating AS
3. 生成 AS からの経路集約
It has been well recognized that address allocation and address
renumbering are keys to containing the growth of the Internet routing
table [1, 2, 8, 9, 11, 12].
アドレス割り当てとアドレス再割り当てが、the Internet のルーティング
テーブル成長を押えるための鍵であることは、よく認識されてきている
[1, 2, 8, 9, 11, 12]。
Although the strategies discussed in this document do not assume a
perfect address allocation, it is strongly urged that an AS receive
allocation from its upstream service providers' address block.
この文書で記述される戦略は完全なアドレス割り当てをとると思わないけれ
ども、AS がその上位プロバイダのアドレスブロックから割り当てを受信す
ることを、強く主張する。
3.1 Intra-Domain Aggregation
3.1 ドメイン内における経路集約
To reduce the number of routes that need to be injected into an AS,
there are a couple of principles that shall be followed:
AS へと注入される必要がある経路数を減らすため、従われるべき 2 つの法
則がある:
- Carry in its BGP table the large route block allocated from its
upstream provider or an address registry (e.g., InterNIC, RIPE,
APNIC). This can be done by either static configuration of the
large block or by aggregating more specific BGP routes. The
former is recommended as it does not depend on other routes.
その上流プロバイダ、またはアドレスレジストリ (たとえば、
InterNIC, RIPE, APNIC) から割り当てられた大きな経路ブロックを、
その BGP テーブルへと持っていく。これは、大きなブロックの静的コ
ンフィギュレーションか、より個別である BGP 経路を集約するかのど
ちらかにより、おこなわれることができる。前者は、他の経路に依存
しないので、推奨される。
- Allocate sub-blocks to the access routers where further
allocation is done. That is, the address allocation shall be
done such that only a few, less specific routes (instead of many
more, specific ones) need to be known to the other routers
within the AS.
サブブロックを、さらなる割り当てがおこなわれるアクセスルータへ
と割り当てる。すなわち、(多くの、より個別である経路のかわりに)
少しの、より個別でない経路のみが AS 内での他のルータに知られて
いる必要のあるという方法で、アドレス割り当てがおこなわれるべき
である。
For example, a prefix of /17 can be further allocated to
different access routers as /20s which can then be allocated to
customers connected to different interfaces on that router (as
shown in Figure 2). Then in general only the /20 needs to be
injected into the whole AS. Exceptions need to be made for
multi-homed static routes.
たとえば、prefix /17 は、/20 である異なるアクセスルータへと、さ
らに割り当てられることができる。この /20 は、(Figure 2 で示され
るとして) そのルータ上で異なるインターフェイスに接続される
customer(s) へと割り当てられる。それから一般に、/20 のみは、AS
全体へと注入される必要がある。例外は、マルチホームされた静的経
路へとおこなわれる必要があるということである。
access router
+------------+
| x.x.x.x/20 |
+------------+
| | |
| | |
/24 /22 /25
Figure 2
図 2
It is noted that rehoming of customers without renumbering even
within the same AS may lead to injection of more specific routes.
However, in general the more-specifics do not need to be advertised
outside of that AS. Such routes can either be tagged with the BGP
community "no-export" or filtered out by a prefix-based filter to
prevent them from being advertised out.
同じ AS 内でさえ、renumbering (再番号づけ) なしに customer(s) の
rehoming (再割り当てすること ?) は、より個別である経路の注入を引き起
こすかもしれないことに注意しなさい。しかしながら一般に、より個別であ
る経路は、その AS 外へと広告される必要はない。そのような経路が外へと
広告されるのを防ぐため、それら経路は、BGP コミュニティ "no-export"
でタグづけされるか、プレフィックスベースのフィルタによる外向きにフィ
ルタされるかのどちらかでありうる。
3.2 Inter-Domain Aggregation
3.2 ドメイン間における経路集約
There are at least two types of routes that need to be advertised by
an AS: routes originated by the AS and routes originated by its BGP
customers. An AS may need to advertise full routes to certain BGP
customers, in which case the routing announcements include routes
originated by non-customer ASs. Clearly an AS can, and should,
safely aggregate the routes originated by itself and by its BGP
customers multi-homed only to it (using, e.g., the dedicated-AS and
by the private-AS mechanism [10]) in its outbound announcement. But
it is far more dangerous to aggregate routes originated by customer
ASs due to multi-homing.
AS により広告される必要がある経路について、少なくとも 2 つのタイプが
ある: AS により生成された経路と、その BGP customer(s) により生成され
た経路である。AS は、確実なピアへと full routes (全経路) を広告する
必要があるかもしれない。そのようなケースで、ルーティング広告は、
customer でない AS(s) により生成された経路を含む。明らかに、AS は、
それ自身、かつそのマルチホームされた BGP customer(s) のみにより生成
された経路を、安全に集約されることができ、かつされるべきである。これ
は、その外向き広告に、(たとえば、使用している専用 AS とプライベート
AS メカニズム [10] による) ピアに対してである。しかし customer AS(s)
により生成された経路を集約することは、マルチホーム化のために、はるか
に危険である。
However, there are several cases in which a route originated by a BGP
customer (other than using the dedicated AS or private AS) does not
need to be advertised out by its upstream providers. For example,
しかしながら、(専用 AS やプライベート AS の使用と異なり) BGP
customer により生成された経路は、上流プロバイダにより外へ広告される
必要がない、といういくつかのケースがある。
- The route is a more-specific of the upstream provider's block.
However, the customer is either singly homed; or its connection
to this particular upstream provider is used for backup only.
経路は、上流プロバイダのブロックのうち、より個別である。しかし
ながら customer は、単一のホームか、この特定の上流プロバイダが
バックアップのみに使用される、そのプロバイダへのコネクションの
どちらかである。
- The more-specifics of a larger block are announced by the
customer in order to balance traffic over the multiple links to
the upstream provider.
より大きなブロックのより個別な経路は、上流プロバイダへの複数リ
ンク上でのトラフィックのバランスを取るため、customer により広告
される。
Our approach to suppress such routes is to give control to the ASs
that originate the more-specifics (as seen by its upstream providers)
and let them tag the BGP community "no-export" to the appropriate
routes.
そのような経路を抑制するためのわれわれの方法は、AS(s) に制御を与える
ことである。その制御とは、(上流プロバイダにより見られる) より個別で
ある経路を生成し、それら適切な経路へと BGP コミュニティ "no-export"
をタグづけさせることである。
The BGP community "no-export" is a well known BGP community [6, 7].
A route with this attribute is not propagated beyond an AS boundary.
So, if a route is tagged with this community in its announcement to
an upstream provider and is accepted by the upstream provider, the
route will not be announced beyond the upstream provider's AS. This
achieves the goal of suppressing the more-specifics in the upstream
provider's outbound announcement.
BGP コミュニティ "no-export" は、よく知られた BGP コミュニティ
[6, 7] である。この属性を持つ経路は、AS 境界を越えて広告されない。そ
れで、もし上流プロバイダへの広告時に、経路がこのコミュニティでタグづ
けされ、かつ上流プロバイダにより受け入れられるなら、経路は、上流プロ
バイダを越えて広告されない。これは、上流プロバイダの外向き広告に、よ
り個別である経路を抑制する目的を達成する。
In this framework, the BGP community "no-export" shall be tagged to
routes that are to be advertized to, but not propagated by, its
upstream provider. They may include routes allocated out of its
upstream provider's block or the more specific routes announced to
its upstream provider for the purpose of load balancing. This
aggregation strategy can be implemented via prefix-based filtering as
shown in the example of Section 5.
この枠組で、BGP コミュニティ "no-export" は、経路をタグづけされるべ
きである。この経路は、その上流プロバイダへと広告されるが、(コミュニ
ティ "no-export" により) その上流プロバイダから伝達されない。これら
経路は、その上流プロバイダのブロックの中から外へと割り当てられた経路
か、ロードバランス目的のために上流プロバイダへと広告される、より個別
である経路を含むだろう。この集約戦略は、Section 5 の例で見られるとし
て、プレフィックスベースフィルタリングで実装されることができる。
For its own protection, a downstream AS shall announce only its own
routes and its customer routes to its upstream providers. Thus, the
outbound routing announcement and aggregation policy can be expressed
as follows:
自分自身の保護のために、下流プロバイダは、自分自身の経路のみと、その
customer 経路を、上流プロバイダへと広告すべきである。したがって、外
向きルーティング広告と集約ポリシーは、次のように表現されることができ
る:
For routes originated by itself/dedicated-AS/private-AS:
自分自身/専用 AS/プライベート AS により生成された経路について:
tag with "no-export" when appropriate, and advertise the
large block and suppress the more-specifics
適切な時 "no-export" でタグづけし、大規模ブロックを広告し、そ
して、より個別である経路を抑制する
For routes originated by customer ASs:
customer AS(s) により生成された経路について:
advertise to upstream ASs
上位 ASs へと広告
For any other routes:
他のどんな経路について:
do not advertise to upstream ASs
上位 ASs へと広告しない
This approach is flexible and scales well as it gives control to the
party with the special needs, distributes the workload and avoids the
coordination overhead required by proxy aggregation.
この方法は、柔軟であり、よくスケールする。理由は、特別な必要性がある
パーティに制御を与え、負担を分配し proxy aggregation により必要とさ
れるオーバヘッドを回避するからである。
-----------------------------------------------------------------------
4. Aggregation by a Provider
4. プロバイダによる経路集約
A provider shall aggregate all the routes it originates, as
documented in Section 3. The only difference is that the provider
may be providing full routes to certain BGP customers where no
outbound filtering is presently in place. Experience has shown that
inconsistent route announcement (e.g., aggregate at the interconnects
but not toward certain customers) can cause serious routing problems
for the Internet as a whole because of longest-match routing. In
certain cases announcing the more-specifics to customers might
provide for more accurate IGP metrics and could be useful for better
load-balancing. However, the potential risk seems to outweigh the
benefit, especially given the increasing complexity of connectivity
that a customer may have. As a result, every effort shall be made to
ensure consistent route aggregation for all BGP peers. This means
deploying filters for the BGP peers which receive full routes.
プロバイダは、Section 3 で記述されたとして、生成したすべての経路を集
約すべきである。唯一の違いは、そのプロバイダが、信頼できるピアに外向
きフィルタリングが現在設定していないで、 full routes を提供している
ことである。一貫性のない経路広告 (たとえば、相互接続に対して集約する
が、確実な customer に対してではない) は、longest match (最長マッチ)
ルーティングのために、全体として the Internet に重大なルーティング問
題を引き起こしうる。特定のケースで、customer(s) へとより個別である経
路を広告することは、より正確な IGP メトリックを与えるかもしれなく、
よりよい load-balancing に有用であるかもしれない。しかしながら、潜在
的な危険が恩恵にまさるように見える。その危険とは、特に customer が持
つだろう接続可能性の増大する複雑さが与えられるということである。結果
として、全努力は、全 BGP ピアへの一貫した経路集約を保証させる。これ
は、full routes を受信する BGP ピアについて、フィルタの配置を意味す
る。
In summary, the aggregation strategy for a provider shall be:
要約すると、プロバイダのための集約戦略は、次の通りである:
- In announcing customer routes:
customer 経路を広告時:
For routes originated by itself/dedicated-AS/private-AS:
自分自身/専用 AS/プライベート AS により生成された経路について:
tag with "no-export" when appropriate, and advertise the
large block and suppress the more-specifics
適切な時 "no-export" でタグづけし、大規模ブロックを広告し、
そして、より個別である経路を抑制する
For routes originated by other customer ASs:
他の customer(s) AS(s) により生成された経路について:
advertise
広告
For any other routes:
他のどんな経路について:
do not advertise
広告せず
- In announcing full routes:
全経路広告:
For routes originated by itself/dedicated-AS/private-AS:
自分自身/専用 AS/プライベート AS により生成された経路について:
tag with "no-export" when appropriate, and advertise the
large block and suppress the more-specifics
適切な時 "no-export" でタグづけし、大規模ブロックを広告し、
そして、より個別である経路を抑制する
For any other routes:
他のどんな経路について:
advertise
広告
-----------------------------------------------------------------------
5. An Example
5. 例
Consider the example shown in Figure 3 where AS 1000 is a "Tier 1"
provider with two large aggregates 208.128.0.0/12 and 166.55.0.0/16,
and AS 2000 is a customer of AS 1000 with a "portable address"
160.75.0.0/16 and an address 208.128.0.0/19 allocated from AS 1000.
Assume that 208.128.0.0/19 does not need to be propagated beyond AS
1000.
Figure 3 で示される例を考えなさい。これは、AS 1000 が 2 つの大規模集
約 (経路) 208.128.0.0/12 と 166.55.0.0/16 を持つ "Tier 1" プロバイダ
であり、AS 2000 が "portable address" 160.75.0.0/16 と AS 1000 から
割り当てられたアドレス 208.128.0.0/19 を持つ AS 1000 の customer で
あるというケースである。208.128.0.0/19 は、AS 1000 を越えて伝達され
る必要はないと想定しなさい。
+----------------+
| AS 1000 |
| 208.128.0.0/12 |
| 166.55.0.0/16 |
+----------------+
|
| BGP
|
|
+----------------+
| AS 2000 |
| 208.128.0.0/19 |
| 160.75.0.0/16 |
+----------------+
Figure 3
図 3
Then, based on the framework presented, AS 1000 would
それから、示された枠組に基づいて、AS 1000 は次のことをおこなう
- originate and advertise the BGP routes 208.128.0.0/12 and
166.55.0.0/16, and suppress more-specifics originated by
itself/private-ASs/dedicated-ASs
BGP 経路 208.128.0.0/12 と 166.55.0.0/16 を生成し広告する。そし
て自分自身/プライベート AS(s)/専用 AS(s) により生成されている、
より個別である経路を抑制する。
- advertise the routes received from the customer AS 2000
顧客 AS 2000 から受信された経路を広告
and AS 2000 would
そして AS 2000 は次のことをおこなう
- originate BGP route 208.128.0.0/19 and 160.75.0.0/16
BGP 経路 208.128.0.0/19 と 160.75.0.0/16 を生成
- advertise both 160.75.0.0/16 and 208.128.0.0/19 to its provider
AS 1000 and suppress the more specifics originated by
itself/private-AS/dedicated-AS, tagging the route 208.128.0.0/19
with "no-export"
160.75.0.0/16 と 208.128.0.0/19 両方をそのプロバイダ AS 1000 へ
と広告する。そして 経路 208.128.0.0/19 を "no-export" でタグづ
けして、それ自身/プライベート AS/専用 AS により生成された、より
個別である経路を抑制する。
- advertise both 160.75.0.0/16 and 208.128.0.0/19 to its BGP
customers (if any) and suppress the more-specifics originated by
itself/private-AS/dedicated-AS, plus any other routes the
customers may desire to receive
160.75.0.0/16 と 208.128.0.0/19 両方を、(もしあるなら) その BGP
customer へと広告する。そして、customer(s) が受信を望む他のどん
な経路も加えて、それ自身/プライベート AS/専用 AS により生成され
た、より個別である経路を抑制する。
The sample configuration which implement these policies (in Cisco
syntax) is given in Appendix A.
(Cisco 構文での) これらポリシーを実装したサンプル設定は、Appendix A
で与えられる。
-----------------------------------------------------------------------
6. Acknowledgments
6. 謝辞
The authors would like to thank Roy Alcala of MCI for a number of
interesting hallway discussions related to this work. The IETF's IDR
Working Group also provided many helpful comments and suggestions.
著者たちは、この仕事に関連した玄関先での興味ある多数の討論について、
MCI の Roy Alcala に感謝したい。IETF の IDR Working Group は多くの役
立つコメントと提案も提供してくれた。
-----------------------------------------------------------------------
7. References
7. 参考文献
[1] Rekhter, Y. and T. Li, "An Architecture for IP Address Allocation
with CIDR", RFC 1518, September 1993.
[2] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-
Domain Routing (CIDR): an Address Assignment and Aggregation
Strategy", RFC 1519, September 1993.
[3] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[4] Rekhter, Y. and P., Gross, "Application of the Border Gateway
Protocol in the Internet", RFC 1772, March 1995.
[5] Rekhter, Y., "Routing in a Multi-provider Internet", RFC 1787,
April 1995.
[6] Chandra, R., Traina, P. and T. Li, "BGP Communities Attribute",
RFC 1997, August 1996.
[7] Chen, E. and T. Bates, "An Application of the BGP Community
Attribute in Multi-home Routing", RFC 1998, August 1996.
[8] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: Why
would I want it and what is it anyway?", RFC 2071, January 1997.
[9] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January
1997.
[10] Stewart, J., Bates, T., Chandra, R., and Chen, E., "Using a
Dedicated AS for Sites Homed to a Single Provider", RFC 2270,
January 1998.
[11] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
Behaviour Today", RFC 2101, February 1997.
[12] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
1900, February 1996.
[13] Cisco systems, Cisco IOS Software Version 10.3 Router Products
Configuration Guide (Addendum), May 1995.
-----------------------------------------------------------------------
8. Authors' Addresses
8. 著者のアドレス
Enke Chen
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134-1706
Phone: +1 408 527 4652
EMail: enkechen@cisco.com
John W. Stewart, III
Juniper Networks, Inc.
385 Ravendale Drive
Mountain View, CA 94043
Phone: +1 650 526 8000
EMail: jstewart@juniper.net
-----------------------------------------------------------------------
A. Appendix A: Example Cisco Configuration
A. 付録 A: Cisco 設定例
This appendix lists the Cisco configurations for AS 2000 of the
examples presented in Section 5. The configuration here uses the
AS-path for outbound filtering although it can also be based on BGP
community. Several route-maps are defined that can be used for
peering with the upstream provider, and for peering with customers
(announcing full routes or customer routes).
この付録は、Section 5 で示された例での AS 2000 に関する Cisco 設定を
リストする。この設定は、BGP コミュニティに基づいてもできるけれども、
外向きフィルタリングの AS パスを使用する。いくつかの route-map(s) は
(全経路や顧客経路を広告することになる) 上流プロバイダとのピアリング
と、顧客とのピアリングに使用されることができる。
!!# inject aggregates
ip route 160.75.0.0 255.255.0.0 Null0 254
ip route 208.128.0.0 255.255.224.0 Null0 254
!
router bgp 2000
network 160.75.0.0 mask 255.255.0.0
network 208.128.0.0 mask 255.255.224.0
neighbor x.x.x.x remote-as 1000
neighbor x.x.x.x route-map export-routes-to-provider out
neighbor x.x.x.x send-community
!
!!# match all
ip as-path access-list 1 permit .*
!
!!# List of internal AS and private ASs that are safe to aggregate
ip as-path access-list 10 permit ^$
ip as-path access-list 10 permit ^64999_
ip as-path access-list 10 deny .*
!
!!# list of other customer ASs
ip as-path access-list 20 permit ^3000_
!!# List of prefixes to be tagged with "no-export"
access-list 101 permit ip 208.128.0.0 0.0.0.0 255.255.224.0 0.0.0.0
!!# Filter out the more specifics of large aggregates, and permit the rest
access-list 102 permit ip 160.75.0.0 0.0.0.0 255.255.0.0 0.0.0.0
access-list 102 deny ip 160.75.0.0 0.0.255.255 255.255.128.0 0.0.127.255
access-list 102 permit ip 208.128.0.0 0.0.0.0 255.255.224.0 0.0.0.0
access-list 102 deny ip 208.128.0.0 0.0.31.255 255.255.240.0 0.0.16.255
access-list 102 permit ip any any
!
!!# route-map with the upstream provider
route-map export-routes-to-provider permit 10
match ip address 101
set community no-export
route-map export-routes-to-provider permit 20
match as-path 10
match ip address 102
route-map export-routes-to-provider permit 30
match as-path 20
!
!!# route-map with BGP customers that desire only customer routes
route-map export-customer-routes permit 10
match as-path 10
match ip address 102
route-map export-customer-routes permit 20
match as-path 20
!
!!# route-map with BGP customers that desire full routes
route-map export-full-routes permit 10
match as-path 10
match ip address 102
route-map export-full-routes permit 20
match as-path 1
!
-----------------------------------------------------------------------
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (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.
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.
一覧
スポンサーリンク
