⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc2260.txt

📁 很多RFC的中文文档
💻 TXT
📖 第 1 页 / 共 2 页
字号:
                          |  /+/     EBGP   |
                     +-------+           +-------+
                     |E-BR-A|---------------|E-BR-B |
                     +------+    IBGP   +-------+
图2 依靠非直连EBGP广告的可达性信息。
5.3 综合两种方法
我们能够观察到虽然在5.2节描述的实现允许完全的消除由于多宿主机构给Internet上的“默认-树”区域带来的路由负担,但它可能在链路失效时导致一个不是最优化的路由。这种非最优化可以通过结合5.2节描述的实现和5.1节描述的加一些轻微修改的实现来减轻。修改包括限制一个边缘路由器广告的额外路由器的范围,当路由器检测到通过它的其它边缘路由器到Internet连接性的问题时。一个限制这样的范围的方法是使用BGP团体属性(Community attribute)【RFC1997】。
5.4 稳定状态下的更佳(更优化的)路由
本文档描述的实现假定,在一个稳定的状态下,一个机构的边缘路由器会向一个直接连接的ISP边缘路由器只广告此ISP分派给机构的地址前缀的可达性。这样做的结果便是由连接到此ISP的其它机构产生并路由到非其它地址前缀机构部分的流量不会在这个边缘路由器进入机构,这导致潜在的非优化路径。为了改变此情形,边缘路由器可以(处于稳定状态)不仅广告此和此路由直接相连的ISP分派的地址前缀,而且广告由一些其它ISP(和机构的其它边缘路由器直接相连)分派的地址前缀。这样的广告报文的分发应该要谨慎,否则这可能会导致在Internet的“默认-树”区域要维护显著增多的额外路由信息。一个限制这样的广告报文的分发的一种方法是使用BGP的团体属性【RFC1997】。
6 和其它实现方法的比较
CIDR【RFC1518】建议了好几个为连接到多ISP的多宿主机构的可能的地址分派策略。以下简要的回顾目前正在使用的可选方法,并且拿它们和上面描述的实现加以比较。
6.1 解决方法1
在【RFC1518】中建议的一个可能的解决方法是对于每一个各自独立的从它所连接的ISP那获得它的IP地址前缀空间的多宿主机构。这允许每个多宿主机构基于一个单一的前缀的IP分配和依靠一个单一前缀概况一组所有IP地址到机构的可达性信息。这种实现方法的优点在于机构的IP地址和任何特定的ISP的地址之间没有联系,由机构广告的可达性信息并不和除了默认路由外的任何其它路由聚合。这在Internet的“默认-树”区域0(N)的路由负担,其中N是穿过整个Internet的连接到多个ISP的多宿主机构的总体数目。
作为一个结果,这种实现不能够被视为一个对除了提供高度足够程度的寻址信息集聚的机构外的所有机构都可行的可选方案。
6.2 解决方法2
另外一个可行的解决方法,在【RFC1518】中建议的,是给每个多宿主机构基于其连接的多个ISP中的一个分派一个单一地址前缀。多宿主机构连接的其它ISP为组织维护一个路由表项地址前缀,这非常的有选择性在于其它的ISP被告知此路由并且会执行“代理”集聚。和此实现相关的大部分复杂性在于执行“代理”集聚的需求,而这正依次需要额外的ISP间的协调和更为复杂的路由器配置。
7 讨论
在本文档描述的实现假定一个机构可能使用的地址是基于“地址主导(address lending)”策略分配。因而,只要一个机构改变它的ISP,此机构就会需要对它的部分网络进行重新编号,这些网络原先是用此ISP分配给机构的地址块进行的编号。然而,这些方面并不是多宿主所特有的,而应该认为是当前因特网公认的实际。本文档所描述的实现有效的消除了任何在单宿主和多宿主机构间的区别,这是在设计改变ISP时重编号的影响。
本文档描述的实现也需要在机构内仔细的地址分配,这是由于地址分配会影响流量在机构和它的所有ISP间多个连接的分发。
地址分配和重新编号的两个方面都会在使用网络地址转换(NAT)时设计到。在多宿主机构内使用NAT超出了此文档的讨论范围。
使用自动路由注入(在5.1节所描述)增加了在Internet的默认树区域的路由数量,和使用提供者-无关地址相比(6.1节所描述的),这会在改变多宿主机构的连接性时收到影响。显而易见,使用自动路由注入,当一个多宿主机构失去它和它的所有ISP中的一个间的连通性时,自动注入路由不得不传播到所有在Internet的默认树区域内的路由器。相反,当一个机构使用提供者-无关地址时,只有一些(不是所有)在默认区域的路由器会看到在一个多宿主机构失去它和它的所有ISP中的一个间的连通性时路由的变化。
为了减少由于链路失效带来的路由负担,自动注入路由不得不被广告直到依靠的其它连接(此连接先前失效且导致了自动路由注入)的连通性变得稳定。
使用非直连的EBGP实现(在5.2节描述)允许消除由于在Internet的默认-树区域的多宿主机构而引起的路由变化。这也就是说,非直连EBGP实现有更好的特性,考虑到比使用提供者-无关地址(在6.1节所介绍的)更好的路由稳定性
8 多宿主ISP的应用
在此文档中描述的实现可以应用到一个小到中等大小的ISP,此ISP连接到多个上行ISP。此ISP将会从它的多个上行ISP那获得一些地址块(地址前缀),并且将使用这些地址分配给它的客户。不管是自动路由注入,是非直连EBGP实现,还是两者的结合都可能被此ISP使用,当和它的上行ISP对端时。这样做会为它的客户提供路由能力而没有影响整个Internet路由体系的伸缩性。
9 安全性考虑
由于非直连EBGP的实现(在5.2节描述)需要在彼此间超过一个IP跳数的路由器间的EBGP会话,维护这些会话的路由器应该为BGP对端认证使用一个恰当的认证机制。
和IBGP对端相关的安全性,同彼此间超过一个IP跳数的路由器间的EBGP对端的安全性一样都超出了此文档的范围。
10 致谢
此文档的作者没有对在此文档中描述的想法做任何版权所有的要求。任何先前考虑到这些方法的人都应该得到所有应得的权利。
参考
 [RFC1518]
        Rekhter, Y., and T. Li, "An Architecture for IP Address
        Allocation with CIDR", RFC 1518, September 1993.
 [RFC1771]
        Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
        RFC 1771, March 1995.
[RFC1773]
        Hanks, S., Li, T., Farinacci, T., and P. Traina, "Generic
        Routing Encapsulation over IPv4 networks", RFC 1773, October
        1994.
[RFC1918]
        Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot G.J., and
        E. Lear, "Address Allocation for Private Internets", RFC 1918,
        February 1996.
[RFC1997]
        Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute",
        RFC 1997, August 1996.
[RFC2008]
        Rekhter, Y., and T. Li, "Implications of Various Address
        Allocation Policies for Internet Routing", BCP 7, RFC 2008,
        October 1996.
作者地址:
Tony Bates
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
   EMail: tbates@cisco.com

   Yakov Rekhter
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   EMail: yakov@cisco.com
currently provided by the Internet Society.
完整的版权声明
Copyright (C) The Internet Society (2000)。版权所有。
本文档及其译文可以拷贝和提供给他人,且其衍生物,如评论、解释或帮助实施的作品可以全部或部分地定制、拷贝、出版和发布,对此我们不加任何限制,前提是上述版权声明,及本段内容包含在所有的拷贝和派生作品中。然而,本文档本身不允许以任何方式修改,例如删除Internet社团或其他Internet组织的版权声明或参考,除非是为了开发Internet标准的需要。即便在这种情况下,也需要添加Internet标准中定义的版权声明,或者根据需要把他翻译成英语以外的其他语言。
上述准许的有限许可是永久性的, 无论是Internet社团以及其继承者或代理者都将不会废止这些许可。
本文档及其中包含的信息基于“AS IS”提供,而且INTERNET社团和IETF拒绝所有授权、表达或影射,包括但不限于任何这里使用的消息的授权将不会违背任何版权或者隐含的商业性授权或对特定的合理目的。
致谢
目前,RFC编者活动的基金由Internet社团提供。
RFC2260——Scalable Support for Multi-homed Multi-provider Connectivity        对多宿主的多提供者连接的可扩展性支持




1
RFC文档中文翻译计划

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -