Network Working Group E. Chen
Request for Comments: 2519 Cisco
Category: Informational J. Stewart
Juniper
February 1999
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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
本文档介绍了域间路由聚合的框架，并展示了“实现”该框架的路由器配置示例。该框架具有灵活性和可扩展性，它强调了源聚合的理念，包括路由域内聚合和向上游提供商聚合，它还强烈鼓励使用“无导出”BGP社区来平衡提供商-订户对更细粒度路由信息的需求与互联网对可扩展域间路由的需求。
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.
路由聚合的必要性早已被认识到。路由聚合很好，因为它减少了Internet路由表的大小并减缓了其增长。因此，减少了处理路由信息所需的资源量（例如，CPU和内存），并加快了路由计算。路由聚合的另一个好处是路由襟翼的数量、频率和范围有限，这节省了资源，使全球互联网路由系统更加稳定。
Since CIDR (Classless Inter-Domain Routing) [2] was introduced, significant progress has been made on route aggregation, particularly in the following two areas:
自从引入CIDR（无类别域间路由）[2]以来，在路由聚合方面取得了重大进展，特别是在以下两个领域：
- Formulation and implementation of IP address allocation policies by the top registries that conform to the CIDR principles [1].
- 由符合CIDR原则的顶级注册中心制定和实施IP地址分配策略[1]。
This policy work is the cornerstone which makes efficient route aggregation technically possible.
此策略工作是使高效路由聚合在技术上成为可能的基石。
- 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.
- 按大型（尤其是“第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.
然而，不同级别的全局路由系统实现高效聚合方案的能力差别很大。因此，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:
由于路由系统的当前规模及其动态性质，实现此目标的第一步是建立一个明确定义的框架，在该框架中可以实现可伸缩的域间路由聚合。本文件中描述的框架基于互联网的主要和当前经验。它强调源聚合的理念，包括路由域内以及向上游提供商聚合。该框架还大力鼓励使用“无导出”BGP社区来平衡providersubscriber对更细粒度路由信息的需求与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前缀、BGP4和ASs，但这些原则通常适用于域间路由聚合。
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].
用于重新编号整个网络的地址分配策略和技术虽然与实现成功和持续的域间路由非常相关，但不是本文档的重点。参考文献部分包含指向相关文档的指针[8,9,11,12]。
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和专用ASs发起的BGP路由[10]。（“由AS发起的路由”是指在AS path属性中具有AS first的路由。例如，静态配置并注入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进行的路由聚合。这保留了多宿主站点控制注入全局路由系统的路由信息粒度的能力。由于代理聚合涉及多个组织之间的协调，因此代理聚合的复杂性随着参与协调的各方数量的增加而增加。复杂性反过来影响代理聚合的实用性。
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路由。这确保了客户使用BGP“无出口”是安全的。
- Using BGP community "no-export" toward upstream providers
- 对上游供应商使用BGP社区“不导出”
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社区标记为“不导出”到其发起的不需要传播到其上游提供商之外的路由（例如，由上游提供商分配的前缀）。
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.
该框架如图1所示。“1级”提供商在其公告中不使用“不导出”，因为它没有上游提供商。但是，它应将其在向对等提供商和客户发出的出站公告中发起的路线进行汇总。上游供应商的AS应汇总其发起的路线，对于不需要传播到其供应商AS之外的路线，应向其上游供应商使用“无出口”。该递归应适用于路由层次结构的所有级别。
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
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
图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控制是否向其上游提供者注入和/或传播粒度更细的路由。它在不影响路由聚合的情况下促进了多归属。
This framework is detailed in the following sections.
以下各节详细介绍了该框架。
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].
众所周知，地址分配和地址重新编号是遏制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从其上游服务提供商的地址块接收分配。
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的路由数量，应遵循以下几个原则：
- 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.
- 在其BGP表中携带从其上游提供商或地址注册表（例如InterNIC、RIME、APNIC）分配的大型路由块。这可以通过大数据块的静态配置或聚合更具体的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.
例如，前缀/17可以进一步分配给不同的接入路由器，如/20，然后可以分配给连接到该路由器上不同接口的客户（如图2所示）。一般来说，只需将/20注入整个AS。需要为多宿静态路由设置例外情况。
access router
+------------+
| x.x.x.x/20 |
+------------+
| | |
| | |
/24 /22 /25
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.
值得注意的是，即使在同一条路线内，如果重新安排客户而不重新编号，可能会导致注入更具体的路线。然而，一般来说，更具体的内容不需要在该范围之外进行宣传。此类路由可以使用BGP社区“no export”进行标记，也可以通过基于前缀的过滤器进行过滤，以防止它们被公布。
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
AS至少需要宣传两种类型的路由：AS发起的路由和BGP客户发起的路由。AS可能需要向某些BGP客户公布完整的路由，在这种情况下，路由公告包括非客户ASs发起的路由。显然，AS可以并且应该安全地聚合由其自身发起的路由以及由其BGP客户发起的路由，这些路由仅由其多宿（使用专用AS和
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机制[10]）在其出站公告中发布。但由于多归属，聚合由客户发起的路由要危险得多。
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,
然而，在一些情况下，BGP客户发起的路由（使用专用AS或专用AS除外）不需要由其上游提供商公布。例如
- 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.
- 该路线是上游供应商区块的一个更具体的路线。然而，客户要么单独居住；或者它与此特定上游提供程序的连接仅用于备份。
- 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.
- 客户将公布更大数据块的更多细节，以平衡到上游提供商的多条链路上的流量。
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.
我们抑制这类路由的方法是控制产生更多细节的ASs（如其上游供应商所见），并让他们将BGP社区标记为“不导出”到适当的路由。
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社区“无导出”是一个众所周知的BGP社区[6,7]。具有此属性的路由不会传播到AS边界之外。因此，如果一条路线在向上游供应商发布的公告中标记了该社区，并且被上游供应商接受，则该路线不会在上游供应商的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社区“无出口”应标记为向其上游供应商发布广告但不由其传播的路线。它们可能包括从其上游提供商的区块中分配的路由，或者为了负载平衡而向其上游提供商宣布的更具体的路由。这种聚合策略可以通过基于前缀的过滤来实现，如第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:
为了自身的保护，下游AS应仅向其上游供应商公布其自身路线和客户路线。因此，出站路由公告和聚合策略可以表示为：
For routes originated by itself/dedicated-AS/private-AS: tag with "no-export" when appropriate, and advertise the large block and suppress the more-specifics
对于源自自身/专用AS/private AS的路由：在适当情况下标记“无导出”，并公布大数据块并抑制更多细节
For routes originated by customer ASs: advertise to upstream ASs
对于客户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.
这种方法具有灵活性和可扩展性，它为具有特殊需求的一方提供控制，分配工作负载，并避免代理聚合所需的协调开销。
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.
如第3节所述，供应商应汇总其发起的所有路线。唯一的区别是，提供商可能向某些BGP客户提供完整的路由，而这些客户目前没有进行出站筛选。经验表明，由于最长匹配路由，不一致的路由公告（例如，在互连处聚合，但不针对特定客户）可能会对整个互联网造成严重的路由问题。在某些情况下，向客户公布更多细节可能会提供更准确的IGP指标，并有助于实现更好的负载平衡。然而，潜在的风险似乎大于好处，特别是考虑到客户可能拥有的日益复杂的连接性。因此，应尽一切努力确保所有BGP对等点的一致路由聚合。这意味着为接收完整路由的BGP对等方部署筛选器。
In summary, the aggregation strategy for a provider shall be:
总之，供应商的聚合策略应为：
- In announcing customer routes:
- 在公布客户路线时：
For routes originated by itself/dedicated-AS/private-AS: tag with "no-export" when appropriate, and advertise the large block and suppress the more-specifics
对于源自自身/专用AS/private AS的路由：在适当情况下标记“无导出”，并公布大数据块并抑制更多细节
For routes originated by other customer ASs: advertise
对于其他客户发起的路线：广告
For any other routes: do not advertise
对于任何其他路线：不要做广告
- In announcing full routes:
- 在公布完整路线时：
For routes originated by itself/dedicated-AS/private-AS: tag with "no-export" when appropriate, and advertise the large block and suppress the more-specifics
对于源自自身/专用AS/private AS的路由：在适当情况下标记“无导出”，并公布大数据块并抑制更多细节
For any other routes: advertise
对于任何其他路线：广告
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.
考虑图3中所示的示例，其中AS 1000是一个“层1”提供程序，具有两个大集合2081280.0/12和1665.5.0.0/16，并且AS 2000是As 1000的客户，具有“便携式地址”160.75.0.0/16和从AS 1000分配的地址2081280.0/19。假设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 |
+----------------+
+----------------+
| 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
然后，根据提出的框架，如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，并抑制由自身/专用ASs/专用ASs发起的更多细节
- advertise the routes received from the customer AS 2000
- 将从客户处收到的路线宣传为2000
and AS 2000 would
就像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作为1000向其提供商宣传，并抑制由其自身/专用AS/专用AS发起的更多细节，将路线208.128.0.0/19标记为“无出口”
- 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
- 向其BGP客户（如有）宣传160.75.0.0/16和208.128.0.0/19，并抑制由其自身/私人AS/专用AS发起的更多细节，以及客户可能希望接收的任何其他路线
The sample configuration which implement these policies (in Cisco syntax) is given in Appendix A.
附录A中给出了实现这些策略的示例配置（Cisco语法）。
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工作组也提供了许多有用的意见和建议。
[1] Rekhter, Y. and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993.
[1] Rekhter，Y.和T.Li，“使用CIDR的IP地址分配架构”，RFC 1518，1993年9月。
[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.
[2] Fuller，V.，Li，T.，Yu，J.和K.Varadhan，“无类域间路由（CIDR）：地址分配和聚合策略”，RFC 1519，1993年9月。
[3] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[3] Rekhter，Y.和T.Li，“边境网关协议4（BGP-4）”，RFC 17711995年3月。
[4] Rekhter, Y. and P., Gross, "Application of the Border Gateway Protocol in the Internet", RFC 1772, March 1995.
[4] Rekhter，Y.和P.，Gross，“互联网中边界网关协议的应用”，RFC 1772，1995年3月。
[5] Rekhter, Y., "Routing in a Multi-provider Internet", RFC 1787, April 1995.
[5] Rekhter，Y.，“多提供商互联网中的路由”，RFC 1787，1995年4月。
[6] Chandra, R., Traina, P. and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
[6] Chandra，R.，Traina，P.和T.Li，“BGP社区属性”，RFC 1997，1996年8月。
[7] Chen, E. and T. Bates, "An Application of the BGP Community Attribute in Multi-home Routing", RFC 1998, August 1996.
[7] Chen，E.和T.Bates，“BGP社区属性在多家路由中的应用”，RFC 1998，1996年8月。
[8] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC 2071, January 1997.
[8] Ferguson，P.和H.Berkowitz，“网络重新编号概述：我为什么想要它以及它到底是什么？”，RFC 2071，1997年1月。
[9] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
[9] Berkowitz，H.，“路由器重新编号指南”，RFC 2072，1997年1月。
[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.
[10] Stewart，J.，Bates，T.，Chandra，R.，和Chen，E.，“使用专用AS，用于单一提供商的站点”，RFC 22701998年1月。
[11] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[11] Carpenter，B.，Crowcroft，J.和Y.Rekhter，“今天的IPv4地址行为”，RFC21011997年2月。
[12] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
[12] Carpenter，B.和Y.Rekhter，“重新编号需要工作”，RFC 1900，1996年2月。
[13] Cisco systems, Cisco IOS Software Version 10.3 Router Products Configuration Guide (Addendum), May 1995.
[13] 思科系统，思科IOS软件版本10.3路由器产品配置指南（附录），1995年5月。
Enke Chen Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706
Enke Chen思科系统有限公司加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134-1706
Phone: +1 408 527 4652
EMail: enkechen@cisco.com
Phone: +1 408 527 4652
EMail: enkechen@cisco.com
John W. Stewart, III Juniper Networks, Inc. 385 Ravendale Drive Mountain View, CA 94043
约翰·W·斯图尔特，III Juniper Networks，Inc.加利福尼亚州山景城拉文代尔大道385号，邮编94043
Phone: +1 650 526 8000
EMail: jstewart@juniper.net
Phone: +1 650 526 8000
EMail: jstewart@juniper.net
A. Appendix A: Example Cisco Configuration
A.附录A：思科配置示例
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).
本附录列出了AS 2000的Cisco配置以及第5节中给出的示例。此处的配置使用AS路径进行出站筛选，尽管它也可以基于BGP社区。定义了多个路由图，可用于与上游提供商的对等以及与客户的对等（宣布完整路由或客户路由）。
!!# 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_
!!# 注入聚合ip路由160.75.0.0 255.255.0.0 Null0 254 ip路由208.128.0.0 255.255.224.0 Null0 254！路由器bgp 2000网络160.75.0.0掩码255.255.0.0网络208.128.0.0掩码255.255.224.0邻居x.x.x.x远程为1000邻居x.x.x.x路由图导出路由到提供商输出邻居x.x.x.x发送社区！！！#匹配所有ip作为路径访问列表1许可证。*！！！#可以安全聚合ip作为路径访问列表10 permit^$ip作为路径访问列表10 permit ^64999\uuuIP作为路径访问列表10 deny其他客户ASs ip as路径访问列表20许可^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 !
!!# 要标记为“无导出”访问列表101的前缀列表允许ip 208.128.0.0.0.0.0 255.255.224.0 0.0.0！！#过滤掉大骨料的更多细节，和允许其余访问列表102允许ip 160.75.0.0.0.0.0 255.255.0.0.0.0.0访问列表102拒绝ip 160.75.0.0 0.0.255.255.255.128.0.0.127.255访问列表102允许ip 208.128.0.0.0 255.224.0.0.0.0访问列表102拒绝ip 208.128.0.0.0.0.31.255.255.255.240.0.0.16.255访问列表102允许任何ip！
!!# 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
!!# 带有上游供应商的路线图路线图导出至供应商许可证的路线10匹配ip地址101设置社区无导出路线图导出至供应商许可证的路线20匹配为路径10匹配ip地址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 !
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 !translate error, please retry
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。