详情
本书深入系统地阐述了TCP/IP路由技术，内容包括几种重要的网络协议，如外部网关协议(EGP)、边界网关协议(BGP4)，以及相应的高级IP路由技术与应用——网络地址转换、IP组播路由技术、IPv6技术、路由器管理等。本书内容全面，可读性强，含有协议配置、网络实施、故障排除等方面的大量实例，是备战CCIE认证考试的经典之作，适合准备参加CCIE考试的人员、网络与通信系统工程技术人员阅读。
书名：TCP/IP路由技术（第2卷）（第2版）
ISBN：978-7-115-46100-1
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
• 著 [美] Jeff Doyle
译 夏俊杰
责任编辑 傅道坤
• 人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
• 读者服务热线：(010)81055410
反盗版热线：(010)81055315
Routing TCP/IP, Volume II, Second Edition (ISBN: 9781587054709)
Copyright © 2017 Pearson Education, Inc.
Authorized translation from the English language edition published by Cisco Press.
All rights reserved.
本书中文简体字版由美国Pearson Education授权人民邮电出版社出版。未经出版者书面许可，对本书任何部分不得以任何方式复制或抄袭。
版权所有，侵权必究。
本书是有关Cisco外部路由协议和高级IP路由主题的权威指南，是Cisco路由与交换领域实属罕见的经典著作。本书在上一版的基础上进行了全面更新，其可读性、广度和深度相较于上一版有了相当大的改进。
本书主要分为11章，其内容包括域间路由概念、BGP简介、BGP和NLRI、BGP和路由策略、扩展BGP、多协议BGP、IP组播路由简介、协议无关组播、扩展IP组播路由、IPv4到IPv4的网络地址转换（NAT44）、IPv6到IPv4的网络地址转换（NAT64）等。为了方便读者深入掌握各章所学知识，本书提供了大量的案例分析材料，涵盖了协议配置、故障检测和排除等方面。每章在结束时都提供大量的复习题、配置练习和排错练习，以加强读者对所学知识的理解与记忆。
本书除了适合众多备考的准CCIE以及需要通过再认证的CCIE阅读，还非常适合从事大型IP网络规划、设计和实施工作的工程技术人员及网络管理员参考。
Jeff Doyle（CCIE #1919）是Fishtech实验室的研发副总裁，主要研究方向是IP路由协议、SDN/NFV、数据中心架构、MPLS以及IPv6技术。Jeff设计或协助设计完成的大规模IP服务提供商网络以及企业网络遍及六大洲的26个国家，曾经协助日本、中国以及韩国开展IPv6的早期部署，为这些国家的服务提供商、政府机构、军队供应商、设备制造商以及大型企业提供IPv6最佳部署方案的咨询服务。他目前主要为大型企业提供数据中心基础设施、SDN以及SD-WAN等领域的演进咨询服务。
Jeff是《TCP/IP路由技术》（第1卷和第2卷）以及《OSPF和IS-IS详解》的作者，是Software Defined Networking: Anatomy of OpenFlow一书的合著者，同时还是Juniper Networks Routers: The Complete Reference的编辑及特约作者。此外，Jeff还为福布斯、Network World博客及Network Computing博客写作文章。Jeff是洛基山IPv6任务组的奠基人之一（是IPv6论坛会员），并在ISOC（互联网协会）科罗拉多分会的执行委员会任职。
Jeff和他的妻子Sara以及一只名叫Max的牧羊犬住在科罗拉多州的威斯敏斯特。Jeff和Sara的生活非常美满，长期与四个成年子女及一大群孙子孙女们居住在方圆几公里的范围之内。
Khaled W. Abuelenain（CCIE #27401）目前是Acuative公司（Cisco认证的专家级可管理服务合作伙伴）的咨询总监，工作地点位于公司在沙特阿拉伯的EMEA办事处。Khaled获得了双CCIE（R&S和SP）认证，拥有埃及艾因·夏姆斯大学电子与通信工程专业的学士学位，从1997年以来一直是IEEE会员。Khaled在中东拥有14年以上的大型网络设计、运维及优化经验，特别是为跨国服务提供商和移动运营商以及银行、政府机构提供服务。Khaled在路由、BGP、MPLS和IPv6等领域造诣精深，同时还是数据中心技术以及网络可编程领域的专家，对于SDN解决方案中的Python编程技术尤为感兴趣。他还是云计算以及SDN IEEE协会的活跃成员。
Nicolas Michel（CCIE #29410，R&S和DC双CCIE）是一名网络架构师，在路由与交换、数据中心以及统一通信等领域拥有10多年的工作经验。Nicolas曾经是法国空军的前空军中士，服役期间担任的工作角色是网络工程师，参与了多个与北约相关的项目。
Nicolas自2011年开始搬到瑞士，为当地一家领先的网络咨询公司工作。
Nicolas是UEFA EURO 2016年欧洲足球锦标赛的首席UC架构师。
Nicolas喜欢研究各类网络新技术（如SDN、自动化/网络可编程），他的博客是http://vpackets.net。Nicolas还是一家旨在帮助自闭症儿童的非政府组织的负责人。
Nicolas参加了一个开源的网络仿真项目：http://www. unetlab.com/。
目前Nicolas正打算移民到美国。
谨将本书献给我挚爱的妻子，感谢她一直以来对我职业生涯的无私支持，让我在工程师道路上不断前行，没有她就没有今天的我。 同时还要将本书献给我的孩子和我的父母，他们教会我永不放弃，并且享受生活的每一刻。 最后，衷心感谢Jeff Doyle，让我有机会参与本书的写作过程，我从中学到了很多东西，直到现在也不敢相信我是如此的幸运。
—— Nicolas
Darien Hirotsu是一名经验丰富的网络专家，在服务提供商、数据中心以及企业网等领域拥有十多年的工作经验。Darien拥有加州大学圣克鲁斯分校网络工程的硕士学位以及加州州立理工大学圣路易斯奥比斯珀分校的学士学位，同时还获得了多项专家级认证，对SDN中的软件及网络技术非常感兴趣。
Darien希望在此对他的未婚妻Rebecca Nguyen表示衷心的感谢。虽然我在编辑本书的过程中受益良多，但也极为耗时，在此感谢Rebecca在整个编辑过程以及漫长的周末时光中，给予我始终如一的爱、支持与耐心，感谢你为我所做的一切，Rebecca！
Peter Moyer是一名经验丰富的IP/MPLS咨询工程师，近年的研究兴趣是SDN。Peter在IP网络互连领域拥有多厂商工作经验，在本世纪初获得了JNCIE认证，在20世纪90年代后期获得了CCIE认证。Peter是多本IP及SDN网络书籍的合著者及技术编辑，而且还发表了大量与网络主题相关的论文及博客。他目前主要研究大规模数据中心和服务提供商网络（包括教育科研网络领域）。Peter拥有马里兰大学的CMIS学士学位。
谨将本书献给我的妻子Sara，以及我的孩子们Anna、Carol、James及Katherine，同时还献给我的孙子孙女们Claire、Caroline及Sam，他们是我的避风港，让我始终保持理智、谦逊和快乐。
技术书籍的作者就像是一群才华横溢的专业人士的名誉牵头人，本书也毫不例外，就像大家在接受奥斯卡大奖时的演说一样，我也要感谢诸多人士。
首先感谢Khaled Abu El Enian和Nicolas Michel，他们为本书每章的最后增加了很多新的配置示例及排错练习题。此外，Khaled还帮我节约了大量写作时间，编写了第5章“扩展BGP功能”小节的大部分内容。衷心希望在未来的写作中能够与他们保持更加密切的合作关系。
还要感谢我的好友兼同事Pete Moyer，他不但是我独自编写的每本书的技术审稿人，而且还与我一同编写了多本图书，Peter对我生命的影响已远远超出本书以及其他图书，我将永远心怀感激。
Darien Hirotsu是本书的另一名技术审稿人，虽然我们在很多企业及工程项目上有过大量合作，但这一次是我们在写作上的首次合作。Darien对于细节有着异乎常人的把握能力，帮我找出了手稿中的大量细节错误。
感谢Chris Cleveland，感谢他作为开发编辑所提供的大量专业指导。我们一起合作了多本图书，是他让我的每一本图书都更加精益求精，也让我成为了一名更加优秀的作者。
感谢Brett Bartow以及Cisco Press的全体同仁，感谢Brett在本书写作期间表现出来的极大耐心，Brett是我写作进度经常滞后的受害者，每天都得将进度控制作为日常工作的头等大事。在我认为他应该拿着本书第1卷敲打我脑袋的时候，他仍然一如既往地表现出了莫大的友善之情。
感谢我的妻子Sara，多年来一直默默地陪我度过了多本图书的编写生涯。每次她看到我茫然地盯着远处时，就会说“你又开始写作啦？ ” 最后，还要感谢你们——我的忠实读者，是你们让这两卷TCP/IP路由技术变得如此成功，并一直耐心地等待我完成这个新版本，希望本书内容值得你们的期待。
自从出版了《TCP/IP路由技术（第1卷）》之后，虽然Cisco Press的“CCIE职业发展系列”增加了大量内容，而且CCIE项目本身也扩展到了多个专业领域，但IP路由协议仍然是所有准CCIE们的核心基础，他们必须透彻理解和掌握，否则基础不牢，大厦将倾。
我在《TCP/IP路由技术（第1卷）》的前言中曾经说过“……随着互连网络规模和复杂性的不断增大，路由问题也将立刻变得庞大且错综复杂”，由于本书重点从IGP转移到了自治系统间的路由问题以及组播和IPv6等诸多特殊路由问题，因而可扩展性和管理性仍然是本书第2卷的核心主题。
本书的写作目的不仅是要帮助读者轻松通过CCIE实验室考试，从而在名字后面加上极具价值的CCIE编号，而且希望帮助读者不断增进知识与技巧，从而无愧于CCIE称号。正如我在《TCP/IP路由技术（第1卷）》中曾经说过的一样，我希望读者成为真正的CCIE，而不仅仅是一名能够通过CCIE实验室考试的人员，因而本书所提供的信息要远远多于通过实验室考试所需的知识。当然，所有信息对于一名受人尊敬的互连网络专家的职业生涯来说都是至关重要的。
在我获得CCIE称号时，CCIE实验室还主要是由AGS+路由器组成的，与那个时代相比，现在的CCIE实验室和考试内容已经发生了翻天覆地的变化，当前实验室考试的难度变得越来越高，而且CCIE项目还增加了再认证要求。在我第一次参加再认证考试之前，有人曾告诉过我《TCP/IP路由技术（第1卷）》对他们准备该考试起到了巨大的作用，特别是IS-IS（该协议几乎没有用在服务提供商的网络之外）。因而我决定写作本书的第2卷，不仅面向众多准CCIE们，而且也面向那些需要通过再认证的CCIE们。有关组播路由及IPv6的章节就是面向这样的读者群的。
我努力遵照《TCP/IP路由技术（第1卷）》的结构来编写第2卷，即首先从通用角度描述某种协议，然后以Cisco IOS为例给出相应的协议配置示例，最后再给出利用Cisco IOS工具检测与排除协议故障的示例，但对于BGP和IP组播来说，如果按照这种结构来编写，那么将会使单章内容变得极为冗长，因而我将其分解成了多个章节。
最后，衷心希望大家阅读本书时获得的知识丝毫不亚于我写作本书所获得的知识。
几乎在本卷第1版于2001年首次发行之后，我就希望增加和修改某些内容，主要原因来自于我不断积累的工作经验。从1998年到2010年，我的工作对象基本上都是服务提供商和运营商，从这些设计项目、技术决策以及主导或参与的众多技术交流中，我学到了很多新知识，当然，有些新知识仅仅弥补了我个人经验上的不足，但并不是所有的新知识都是如此。在BGP及组播网络变得越来越复杂、涌现出大量新功能且最佳实践也在不断发展变化的情况下，我也一直在与业界的发展变化保持同步。
下面将简要描述本书第一版发行之后业界发生的一些新变化。
有关BGP的主要概念都已经在2001年发行的本书第1版中做了详细描述，BGP是一种被互联网广泛使用的外部网关协议（即自治系统间路由协议），具备多协议处理能力，版本4是目前可接受的版本。虽然这些年BGP也增加了一些新的功能特性和协议能力，但协议本身并没有出现大的变化。
主要变化之处在于业界对BGP的使用经验，这些经验不但增强了人们使用BGP策略的方式，而且在某些情况下还改变了传统的最佳实践。此外，多协议BGP已成为多业务核心网的主力，由于多协议BGP允许定义大量新的地址簇，因而可以在单个共享的核心网上运行多种不同的业务。虽然本书并没有讨论多业务网的另一个必要因素——MPLS（Multiprotocol Label Switching，多协议标签交换），这是因为有关MPLS的内容完全可以单出一本或两本专著，但读者完全可以通过本书介绍的这些多协议BGP知识，理解多协议BGP对于各种基于MPLS的地址簇的支持方式。此外，本书还提供了大量配置示例，以帮助读者正确理解多协议BGP在IPv4和IPv6下支持单播和组播地址簇的方式。
本书第1版安排了一个章节专门介绍EGP（BGP的前身），虽然那时已经废止了EGP，但某些政府网络仍在使用该协议，这也是本书在第一版仍然涵盖EGP的主要原因之一，另一个主要原因就是防止某些不循常理的实验室考官在CCIE考试中突然抛出一些EGP考题。考虑到目前该协议已基本绝迹，因而第2版仅在介绍BGP时将EGP作为背景知识进行简要交代。
为了反映业界在BGP使用经验上的不断丰富以及Cisco新支持的大量新BGP功能特性，本书第2版将第1版中有关BGP的2章内容扩展到了6章。
IP组播网络的发展变化可能比BGP网络的发展变化更大，由于组播及其相关联的路由协议极其复杂，因而在2001年的时候还很难管理组播网络。虽然从某种意义上来说，这些困难目前依然存在，但业界出现的一些变化使得这些困难不再高不可攀。
虽然2001年最常见的组播路由协议是DVMRP、PIM-DM和PIM-SM，但当时我推断CBT（Core-Based Tree，核心树）和MOSPF（Multiprotocol OSPF，多协议OSPF）可能会成为主流，因而在第1版中介绍了这方面的内容，不过从目前来看，CBT和MOSPF一直未被接受，DVMRP也成了组播路由协议中的RIP（已被废止，但在某些场合依然能够看到），因而在第2版中删除了有关CBT和MOSPF的全部内容，仅做简单交代，而且与第1版相比，有关DVMRP的介绍也做了大幅简化。
由于PIM已成为当下IPv4和IPv6网络广泛接受的组播路由协议，因而本书第2版更加深入详细地介绍了有关PIM-DM、PIM-SM以及PIM-SSM的内容。
虽然我从1990年代后期就一直倡导和推广IPv6，但截至2001年的时候，对这个新版本IP协议感兴趣的国家还仅限于日本、中国和韩国，美国和欧盟则毫不关心（少数军事领域除外），它们认为IPv6在很大程度上只是面向未知的将来，那时候所有预测公有IPv4地址池将在2012年耗尽的人都被认为是杞人忧天，显得荒谬可笑。因而我在本书第1版单独安排了一章讨论IPv6，与书中其他主题几乎毫无关系。
但这15年确实是天翻地覆的15年，目前IPv6已成为当前的主流协议，估计要不了几年IPv6就将全面替代目前已经耗尽的IPv4。为了反映当前的实际情况，第2版不再将IPv6单独列为一个章节，而是将IPv6的支持要求贯穿于整个BGP及IP组播的讨论当中。
2001年的网络地址转换指的是NAT-PT，一般仅在不同的IPv4地址之间进行转换，十几年来网络地址转换技术得到了极大扩展，因而第2版安排了两章内容来讨论NAT：一章讨论IPv4到IPv4的地址转化；另一章则讨论IPv6到IPv4的地址转换（NAT64）。
第2版在章节安排上的最后一个差异就是去掉了第1版中关于路由器管理的章节（第1版中的第9章），这是因为2001年之后有关Cisco路由器管理的主题变得越来越庞大，Cisco也提供了越来越多的路由平台，必须花费大量篇幅才有可能解释清楚，但这与本书的主旨相悖，而且本书的名字毕竟是TCP/IP路由技术，而不是Cisco路由器管理技术。
第2版的其他变化如下。
读者需要下载两个附录以查看配置练习题和故障检测与排除练习题的答案：附录B和附录C。
读者可在www.epubit.com.cn/book/details/4061的页面上下载这两个附录。
本书在介绍命令语法时使用与IOS命令参考一致的约定，本书涉及的命令参考约定如下：
如果所有网络都使用单一路由协议（如OSPF或IS-IS），那么可以想象如今的互联网会是什么样子。如果每个子网地址均可见的情况下，那么将根本无法保证网络的稳定性。网络的安全性也将脆弱不堪，这是因为针对路由协议的攻击（甚至是一个不起眼的配置差错）都可能会导致整个互联网的瘫痪。此外，谁能管理这样的网络呢？如何在全世界范围内协调所有网络管理员开展协议升级或协议增强等繁琐的维护工作呢？
随着ARPANET（现代互联网的前身）的规模在20世纪70年代后期变得越来越庞大，上述问题也就接踵而至，人们开始尝试创建一种可扩展的方式来管理网络。当时最基本的思路就是创建称为AS（Autonomous System，自治系统）的管理域（AS定义了同一管理权限下的网络边界）以及可在这些管理域之间进行路由的协议（该路由协议对于管理域来说是外部路由协议）。
目前用于自治系统间的路由协议是BGP（Border Gateway Protocol，边界网关协议）。本书将在第2章到第6章描述BGP的功能、配置、故障检测与排除以及各种相关的路由策略。在讨论BGP之前，本书将在第1章介绍BGP背后的关键概念及其演进过程。换句话说，第2章到第6章解释的是如何工作的问题，而第1章解释的则是能做什么以及为什么的问题。
本书第一版花了整章篇幅来解释BGP的前身——EGP（Exterior Gateway Protocol，外部网关协议）。那时的EGP基本处于已经废止状态，只有少数老旧网络仍在使用EGP。几年时间之后，EGP已经被完全废止，IOS也不再支持该协议。
不过EGP可以帮助读者理解当初在设计可操作的域间（即Inter-AS）路由协议时的思路。本节将从技术历史的角度简述EGP的发展历程，以便更好地理解BGP的发展过程。虽然读者也可以选择略过本节，但本节介绍的某些基本概念将一直沿用到BGP上，而且EGP的某些功能还有助于理解BGP设计思路背后的一些概念。
在20世纪80年代早期，组成ARPANET的路由器（网关）设备都运行了一种距离向量路由协议——GGP（Gateway-to-Gateway Protocol，网关到网关协议），每台网关都知道去往每个可达网络的一条路由（以网关跳数来度量距离）。随着ARPANET的不断发展，与当今许多负责管理日益增长的互连网络的网管员一样，ARPANET的架构师们也预见到了相同的问题：当前运行的路由协议缺乏良好的扩展性。
Eric Rosen在RFC 827中阐述了以下扩展性问题。
Rosen在RFC 827中提出的解决方案就是将ARPANET从单一网络迁移到一个相互连接的、自治控制的网络系统。对于每个网络（称为AS）来说，AS的管理权限是完全开放的，可以任意选择本网的管理方式。事实上，自治系统的概念扩展了网络互连的范围，并增加了一个新的分级层次。只要有一个单一互连网络——由多个网络组成的一个网络——就有一个自治系统网络，每个自治系统本身都是一个互连网络。与利用IP地址来标识从AS边界的网络到每个子网的方式类似，AS也要通过自治系统号来加以标识。AS号是一组16比特数字，由负责分配IP地址的编址机构进行分配。
注：
与IP地址类似，AS号也有一些用于私有用途的保留号，这些保留的AS号为64512～65535（详见RFC 6996）。
与部署IPv6的目的是解决IPv4地址不足一样，RFC 4893（目前已被RFC 6793代替）提议使用32比特AS号以避免16比特AS号可能出现的号码不足问题。有关32比特AS号使用问题详见第5章。
对于每个AS的可选管理权限来说，最主要的就是可以任意选择网关所运行的路由协议。由于网关设备位于AS内部，因而它们运行的路由协议也称为IGP（Interior Gateway Protocol，内部网关协议）。由于GGP是ARPANET的路由协议，因而理所当然地被默认为是第一个IGP。不过1982年人们的兴趣集中在更现代（也更简单）的RIP（Routing Information Protocol，路由信息协议）[1]上，认为RIP以及其他计划外的路由协议将用于许多自治系统。目前，GGP已完全被RIP、RIP-2、IGRP（Interior Gateway Routing Protocol，内部网关路由协议）、EIGRP（Enhanced IGRP，增强型IGRP）、OSPF（Open Shortest Path First，开放最短路径优先）版本2和版本3以及集成式IS-IS（Intermediate System-to-Intermediate System，中间系统到中间系统）所取代。
每个AS都通过一个或多个外部网关与其他AS互连在一起。RFC 827提出外部网关之间应该通过EGP协议来共享路由信息。与大家的常见认识不同，虽然EGP是一种距离向量协议，但它并不是一种路由协议，因为EGP没有在网络间选择最优路径的路由算法。更准确地来说，EGP是一种通用语言，外部网关之间利用该语言来相互交换可达性信息。其中，可达性信息是一个包含了主网地址（而不是子网）和网关的简单列表，通过该列表可以到达所有网络和网关。
RFC 827定义的是EGP版本1，版本2对版本1做了少量修改，首次在RFC 888中提出，正式的EGPv2规范则由RFC 904定义。
EGP邻居（也称为对等体[2]）之间需要交换EGP消息。如果邻居位于同一个AS之内，那么就称为内部邻居。如果邻居位于不同的自治系统之内，那么就称为外部邻居。EGP无邻居自动发现功能，需要用手工方式来配置邻居地址，邻居之间交换的消息采用单播方式传送到手工配置的邻居地址。
由于不能将EGP消息传送到单个邻居之外，因而RFC 888建议将EGP消息的TTL（Time-To-Live，生存时间）设置为低值。不过，没有任何一种EGP功能需要EGP邻居共享同一条数据链路。图1-1中的两个EGP邻居被一台仅运行RIP的路由器分隔开。由于EGP消息采用单播方式（而不是广播或多播方式）传送给邻居，因而可以穿越该路由器边界。由于BGP也要用到内部对等体、外部对等体以及单播消息等概念，因而正确理解这些概念非常重要。
图1-1 EGP邻居无需连接在同一个网络上
EGP网关既可以是核心网关，也可以是末梢网关。这两类网关都能接受来自其他自治系统的网络信息，但末梢网关只能发送自身AS中的网络信息，只有核心网关才能发送除自身AS之外的学自其他AS的网络信息。
为了理解EGP定义核心网关与末梢网关的原因，就必须了解EGP在架构方面的局限性。如前所述，EGP并不是一种路由协议，其更新信息仅列出了可达网络，并没有包含确定最短路径或防止路由环路的足够信息。因而建立起来的EGP拓扑结构必须不存在任何环路。
图1-2显示的EGP拓扑结构只有一个核心AS，其他自治系统（末梢自治系统）必须连接在该核心AS上。这种两级树状拓扑结构与OSPF的两级拓扑结构需求非常相似，而且作用也完全相同。在《TCP/IP路由技术（第一卷）》中曾经说过，域间OSPF路由在本质上属于距离矢量路由，因而很容易形成路由环路。因而OSPF要求所有非主干OSPF域之间的流量都必须经过主干域。利用这种强制性的无环路域间拓扑结构，可以大大降低路由环路的可能性。与此类似，要求末梢自治系统间的所有EGP可达性信息都必须经过核心AS，这样就能大大降低EGP拓扑结构潜在的路由环路可能性。
图1-2 为了防止出现路由环路，仅允许核心网关将学自AS的网络信息发送给其他AS
EGP包含以下三种协议机制：
这三种协议机制利用10类消息来建立邻居关系、维护邻居关系、与邻居交换网络可达性信息，并向邻居通告程序差错或格式差错。表1-1列出了所有EGP消息类型以及使用每种消息的协议机制。
下面将逐一讨论上述三种EGP机制。
表1-1 EGP消息类型
| 消息类型 |
协议机制 |
|---|---|
| Neighbor Acquisition Request（邻居获取请求） |
邻居获取 |
| Neighbor Acquisition Confirm（邻居获取确认） |
邻居获取 |
| Neighbor Acquisition Refuse（邻居获取拒绝） |
邻居获取 |
| Neighbor Cease（邻居终止） |
邻居获取 |
| Neighbor Cease Acknowledgment（邻居终止确认） |
邻居获取 |
| Hello |
邻居可达性 |
| I-Heard-You |
邻居可达性 |
| Poll（轮询） |
邻居可达性 |
| Update（更新） |
邻居可达性 |
| Error（差错） |
全部功能 |
EGP邻居在正常交换可达性信息之前，必须首先确认兼容性问题。该功能由一个简单的双向握手过程来完成，由其中的一个邻居发送Neighbor Acquisition Request（邻居获取请求）消息，由另一个邻居响应Neighbor Acquisition Confirm（邻居获取确认）消息。
没有任何一个RFC说明了两个EGP邻居如何初次发现对方。在实际应用中，EGP网关都是通过手工配置邻居的IP地址来获知其邻居的，此后网关就向手工配置的邻居发送单播Neighbor Acquisition Request消息。该消息包含了一个Hello间隔（即网关同意从邻居接受的两条Hello消息之间的最小间隔）和轮询间隔（即网关同意因路由更新而被邻居轮询的最小间隔）。邻居的响应消息Neighbor Acquisition Confirm（邻居获取确认）中也将包含其Hello间隔与轮询间隔。如果邻居双方就这两个间隔值达成一致，那么就可以交换网络可达性信息了。
网关初次学到某个邻居之后，会认为该邻居处于Idle（空闲）状态。在发送第一条Neighbor Acquisition Request消息之前，网关会将邻居的状态切换为Acquire（获取）状态。网关收到Neighbor Acquisition Confirm消息之后，则将邻居的状态切换到Down（停用）状态。
注：
有关EGP有限状态机的详细解释请见RFC 904。
如果网关的响应消息不是Neighbor Acquisition Confirm，而是Neighbor Acquisition Refuse（邻居获取拒绝），那么就表示拒绝该邻居。Neighbor Acquisition Refuse消息中可以包含拒绝理由，如表空间不足。当然，在没有任何特定理由的情况下也可以拒绝邻居。
网关可以利用Neighbor Cease（邻居终止）消息随时终止已经建立的邻居关系。与Neighbor Acquisition Refuse消息一样，发起Neighbor Cease消息的网关既可以在消息中包含终止原因，也可以什么原因都不说。邻居收到Neighbor Cease消息之后，将回应Neighbor Cease Acknowledgment（邻居终止确认）消息。
邻居获取进程的最后一种情况就是网关发送Neighbor Acquisition Request消息，而邻居无任何响应。RFC 888建议“以一个合理的速率（如每隔30 秒）”来重传Neighbor Acquisition Request消息，但Cisco的EGP实现并不仅仅在固定周期内重传未确认的消息，而是在初次发送Neighbor Acquisition Request消息之后的30秒重传未确认的Acquisition（获取）消息，此后在再次重传之前等待60秒钟的时间。如果在第三次重传之后的30秒内仍未收到响应消息，网关就将邻居的状态由Acquire（获取）切换为Idle（见例1-1）。网关将Idle状态保持到300秒（5分钟）之后，会将Idle状态切换到Acquire状态，并重新开始上述邻居获取进程。
注：
以下EGP示例均来自IOS 12.1。
例1-1 命令debug ip egp transactions的输出结果显示了EGP的状态切换信息
Shemp#debug ip egp transactions
EGP debugging is on
Shemp#
EGP: 192.168.16.2 going from IDLE to ACQUIRE
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=0
Type=ACQUIRE, Code=REQUEST, Status=0 (UNSPECIFIED), Hello=60, Poll=180
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=0
Type=ACQUIRE, Code=REQUEST, Status=0 (UNSPECIFIED), Hello=60, Poll=180
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=0
Type=ACQUIRE, Code=REQUEST, Status=0 (UNSPECIFIED), Hello=60, Poll=180
EGP: 192.168.16.2 going from ACQUIRE to IDLE
EGP: 192.168.16.2 going from IDLE to ACQUIRE
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=0
Type=ACQUIRE, Code=REQUEST, Status=0 (UNSPECIFIED), Hello=60, Poll=180
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=0
Type=ACQUIRE, Code=REQUEST, Status=0 (UNSPECIFIED), Hello=60, Poll=180
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=0
Type=ACQUIRE, Code=REQUEST, Status=0 (UNSPECIFIED), Hello=60, Poll=180
EGP: 192.168.16.2 going from ACQUIRE to IDLE
需要注意的是，例1-1中的每条EGP消息都有一个序列号。该序列号可以标识EGP消息对（如Neighbor Acquisition Request/Confirm、Request/Refusal以及Cease/Cease-Ack消息对）。下一节将详细解释序列号的应用方式。
两个EGP网关成为邻居之后，其中一个网关将成为主动邻居，另一个网关将成为被动邻居。始终由主动网关发送Neighbor Acquisition Request消息来发起邻居关系，被动网关从不发送Neighbor Acquisition Request消息，它们仅响应主动网关发出的Neighbor Acquisition Request消息。Hello/I-Heard-You消息对也是如此，由主动邻居发送Hello消息，被动邻居则回应I-Heard-You（I-H-U）消息。不过，被动网关可以发起Neighbor Cease消息，此时主动网关必须回应Neighbor Cease Acknowledgment消息。
核心网关（可以是多个其他自治系统中的路由器的邻居）既可能是某个邻居邻接关系的主动网关，也可能是其他邻居邻接关系的被动网关。Cisco的EGP实现利用AS来作为决定因素，即AS号小的邻居成为主动邻居。
网关获取到某个邻居之后，就通过发送周期性的Hello消息来维护邻居关系，而邻居则以I-H-U消息作为Hello消息的回应。RFC 904没有指定Hello消息的标准周期，Cisco使用的默认周期为60秒。也可以利用命令timers egp进行修改。
交换完Hello/I-H-U消息对之后，邻居的状态就由Down（停用）切换为Up（启用）（见例1-2），此后邻居之间就可以交换网络可达性信息了（如下节所述）。
例1-2 命令debug ip egp transactions的输出结果显示了双向握手成功以及EGP的状态转换
EGP: 192.168.16.2 going from IDLE to ACQUIRE
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=2
Type=ACQUIRE, Code=REQUEST, Status=1 (ACTIVE-MODE), Hello=60, Poll=180
EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=2
Type=ACQUIRE, Code=CONFIRM, Status=2 (PASSIVE-MODE), Hello=60, Poll=180
EGP: 192.168.16.2 going from ACQUIRE to DOWN
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=2
Type=REACH, Code=HELLO, Status=2 (DOWN)
EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=2
Type=REACH, Code=I-HEARD-YOU, Status=2 (DOWN)
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=2
Type=REACH, Code=HELLO, Status=2 (DOWN)
EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=2
Type=REACH, Code=I-HEARD-YOU, Status=2 (DOWN)
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=2
Type=REACH, Code=HELLO, Status=2 (DOWN)
EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=2
Type=REACH, Code=I-HEARD-YOU, Status=2 (DOWN)
EGP: 192.168.16.2 going from DOWN to UP如果主动邻居连续发送了三条消息之后仍未收到响应消息，那么邻居的状态将被切换为Down状态。网关以正常的Hello间隔发送三条以上的Hello消息，如果仍未收到响应消息，那么邻居的状态将被切换为Cease状态。网关按60秒的间隔时间发送三条Neighbor Cease消息，如果邻居均回应Neighbor Cease Acknowledgment消息，那么该网关就将邻居的状态切换为Idle状态，并等待5分钟，之后再切换回Acquire状态，并尝试重新获取邻居。例1-3显示了该事件的顺序关系。
例1-3 地址为192.168.16.2的邻居停止回应，每条未确认的EGP消息的间隔为60秒
Shemp#
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=2
Type=REACH, Code=HELLO, Status=1 (UP)
EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=2
Type=REACH, Code=I-HEARD-YOU, Status=1 (UP)
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=2
Type=REACH, Code=HELLO, Status=1 (UP)
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=2
Type=POLL, Code=0, Status=1 (UP), Net=192.168.16.0
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=3
Type=REACH, Code=HELLO, Status=1 (UP)
EGP: 192.168.16.2 going from UP to DOWN
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=3
Type=REACH, Code=HELLO, Status=2 (DOWN)
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=3
Type=REACH, Code=HELLO, Status=2 (DOWN)
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=3
Type=REACH, Code=HELLO, Status=2 (DOWN)
EGP: 192.168.16.2 going from DOWN to CEASE
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=3
Type=ACQUIRE, Code=CEASE, Status=5 (HALTING)
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=3
Type=ACQUIRE, Code=CEASE, Status=1 (ACTIVE-MODE)
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=3
Type=ACQUIRE, Code=CEASE, Status=1 (ACTIVE-MODE)
EGP: 192.168.16.2 going from CEASE to IDLE例1-4给出了另一个沉寂（Dead）邻居的例子，只是本例中处于被动模式下的核心网关（192.168.16.2）正在发现该沉寂邻居（192.168.16.1）。
例1-4 邻居192.168.16.1停止回应，debug消息来自192.168.16.2（处于被动模式下的核心网关）
Moe#
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=1
Type=REACH, Code=HELLO, Status=1 (UP)
EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=1
Type=REACH, Code=I-HEARD-YOU, Status=1 (UP)
EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=1
Type=POLL, Code=0, Status=1 (UP), Net=192.168.16.0
EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=2
Type=POLL, Code=0, Status=1 (UP), Net=192.168.16.0
EGP: 192.168.16.1 going from UP to DOWN
EGP: 192.168.16.1 going from DOWN to CEASE
EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=3
Type=ACQUIRE, Code=CEASE, Status=5 (HALTING)
EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=3
Type=ACQUIRE, Code=CEASE, Status=2 (PASSIVE-MODE)
EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=3
Type=ACQUIRE, Code=CEASE, Status=2 (PASSIVE-MODE)
EGP: 192.168.16.1 going from CEASE to IDLE如果网关在60秒钟的Hello间隔内未收到Hello消息，那么就会尝试“唤醒”邻居。由于被动模式下的网关无法发送Hello消息，因而发送Poll（轮询）消息，此后网关将等待一个Poll间隔（Cisco的默认Poll间隔是180秒，即3分钟）。如果网关未收到响应消息，那么将再次发送另一条Poll消息，并且再等待一个Poll间隔。如果仍未收到响应消息，那么网关就将邻居的状态更改为Down状态，然后又立即更改为Cease状态。从例1-3可以看出，在发送了三条Cease消息之后，邻居的状态将被更改为Idle状态。
如果邻居的状态为Up，那么EGP邻居之间就可以相互交换可达性信息。每个网关都会周期性地向邻居发送包含了序列号的Poll（轮询）消息，邻居则以包含了相同序列号和可达网络列表的Update（更新）消息进行响应。例1-5显示了IOS使用序列号的方式。
例1-5 EGP邻居相互之间进行周期性轮询以获得网络可达性更新
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=120
Type=REACH, Code=HELLO, Status=1 (UP)
EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=120
Type=REACH, Code=I-HEARD-YOU, Status=1 (UP)
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=120
Type=REACH, Code=HELLO, Status=1 (UP)
EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=120
Type=REACH, Code=I-HEARD-YOU, Status=1 (UP)
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=120
Type=POLL, Code=0, Status=1 (UP), Net=192.168.16.0
EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=120
Type=UPDATE, Code=0, Status=1 (UP), IntGW=2, ExtGW=1, Net=192.168.16.0
Network 172.17.0.0 via 192.168.16.2 in 0 hops
Network 192.168.17.0 via 192.168.16.2 in 0 hops
Network 10.0.0.0 via 192.168.16.2 in 3 hops
Network 172.20.0.0 via 192.168.16.4 in 0 hops
Network 192.168.18.0 via 192.168.16.3(e) in 3 hops
Network 172.16.0.0 via 192.168.16.3(e) in 3 hops
Network 172.18.0.0 via 192.168.16.3(e) in 3 hops
EGP: 192.168.16.2 updated 7 routes
EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=3
Type=POLL, Code=0, Status=1 (UP), Net=192.168.16.0
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=3
Type=UPDATE, Code=0, Status=1 (UP), IntGW=1, ExtGW=0, Net=192.168.16.0
Network 172.19.0.0 via 192.168.16.1 in 0 hops
EGP: from 192.168.16.1 to 192.168.16.2, version=2, asystem=1, sequence=121
Type=REACH, Code=HELLO, Status=1 (UP)
EGP: from 192.168.16.2 to 192.168.16.1, version=2, asystem=2, sequence=121
Type=REACH, Code=I-HEARD-YOU, Status=1 (UP)邻居间交换的每对Hello/I-H-U消息中都包含了相同的序列号，直至发送Poll消息时为止。Poll/Update消息对也使用相同的序列号。主动邻居每收到一次Update消息，就将序列号加1。例1-5中的Poll/Update消息对的序列号为120，加1后变成了121。需要注意的是，本例中两个邻居都发送了Poll消息，来自被动邻居（192.168.16.2）的Poll消息带有完全不同的序列号（3），而邻居总是以包含了与Poll消息中完全相同的序列号的Update消息作为响应消息。
通常来说，网关仅在被轮询时才发送Update消息，这就意味着拓扑结构的变化可能最长有3分钟时间无法向外部进行宣告。因而EGP解决这个问题的方式是允许网关在每个轮询间隔内发送一条主动提供的Update消息，即不是响应Poll消息的Update消息，但IOS不支持这种主动提供的Update消息。
Poll和Update消息都包含源网络地址。从例1-5可以看出，Poll和Update消息中都显示了源网络地址192.168.16.0。这里所说的源网络指的是通过该网络可以测量所有可达性信 息——也就是说，通过连接在源网络上的路由器可以到达所有被请求或被宣告的网络。虽然源网络通常就是与两个邻居都相连的网络，但更准确地说法应该是：源网络是Poll正在请求消息的网络以及Update正在提供信息的网络。EGP是一种有类别协议[3]，而且源网络（与Update中列出的网络地址相同）总是主类网络地址（根本不可能是子网）。
在源网络地址之后是一台或多台路由器以及通过这些路由器可以到达的网络列表。列表上的路由器的共同特征是都连接在源网络上，如果列表上的路由器不是发起Update消息的EGP网关，那么该路由器就是非直连或第三方邻居。
图1-3解释了非直连EGP邻居的概念，名为Moe的路由器是一台核心网关，与其他三台网关形成对等关系。
图1-3 非直连EGP邻居
例1-5中的调试消息来自AS1中的路由器Shemp。从路由器Moe（192.168.16.2）发起的Update消息可以看出，这三个网络均被列为通过路由器Moe可达，有4个网络通过路由器Larry（192.168.16.4）和Curly（192.168.16.3）可达。这两台路由器都是Shemp的邻居，需要经由Moe才能到达。AS3中的路由器Joe则不是一个非直达邻居，因为该路由器并没有连接到源网络上，其网络仅仅被宣告为经路由器Moe可达。
虽然宣告非直达路由器能够节省公共链路带宽，但更重要的是，非直达邻居通过消除不必要的路由器跳数来提升路由效率。从图1-3可以看出，路由器Shemp仅与Moe形成对等关系。事实上，路由器Larry甚至都可能不运行EGP，只是通过RIP将其网络宣告给Moe。路由器Moe通过向Shemp告知有比自己更好的下一跳来执行“抢占重定向”（preemptive redirect）操作。
EGP的Update消息可以仅包含非直达邻居。也就是说，消息的发起方可能不将其作为通往其他网络的下一跳。此时将发起方称为路由服务器。路由服务器通过IGP或静态路由来学习可达性信息，并将这些可达性信息宣告给EGP邻居，而自身并不执行任何包转发功能。
从EGP网关的角度来看，邻居要么是内部网关，要么是外部网关。如果位于同一个AS中，那么邻居就是内部网关。如果位于不同的AS中，那么邻居就是外部网关。图1-3中的所有EGP网关都将邻居视为外部网关。如果路由器Larry也运行了EGP，而且与Moe形成了对等关系，那么这两台路由器都会将对方视为内部网关。
EGP的Update消息包含了两个用来描述其列表中的路由器是内部网关或外部网关的字段。从例1-5的第一条Update消息可以看出，这些字段正好位于源网络地址之前：IntGW=2以及ExtGW=1。这两个字段之和即为Update消息中列出的路由器数量。首先列出的是所有指定的内部网关。因此，如果IntGW=2以及ExtGW=1，那么就表示列出的前两个路由器为内部网关，最后一个路由器为外部网关。如果将例1-5中192.168.16.2的Update消息与图1-3进行比较，可以看出经由路由器Curly可达的三个网络都列在Update消息的最后，并标记为外部，也就是说这三个网络通过路由器Moe的外部网关均可达。由于末梢网关无法将网络宣告到本AS之外，因而只有核心网关的Update消息才包含外部网关信息。
EGP的Update消息为每个列出的网络都关联了一个距离值，距离字段为8个比特，因而距离的取值范围为0～255。不过，除了将255表示为不可达网络之外，RFC 904并没有指定距离值的解析方式，而且也没有RFC定义任何利用该距离值来计算AS间最短路径的算法。IOS将距离值理解为跳数（见例1-5），默认规则很简单：
以例1-5和图1-3为例，尽管网络172.20.0.0与路由器Moe之间存在一跳路由，但Moe宣告该网络时的距离值为0——与直连网络172.17.0.0的距离值相同。Moe与网络10.0.0.0之间存在一跳路由，与网络172.18.0.0之间存在两跳路由，由于这两个网络与Moe处于不同的AS中，因而Moe宣告这两个网络时的距离值都为3。需要记住的是，从本质上来看，EGP使用的距离值对于确定到指定网络的最佳路径来说毫无作用。
例1-6给出了Shemp的路由表以及例1-5中的Update消息所产生的路由项。
例1-6中的路由表有两点值得注意。首先，EGP表项的管理距离为140，该管理距离高于所有IGP（外部EIGRP除外），因而即使EGP宣告的是同一个网络，路由器也总是选择IGP路由。
例1-6 Shemp的路由表
Shemp#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is not set
E 10.0.0.0 [140/4] via 192.168.16.2, 00:00:52, Ethernet0
C 192.168.16.0 is directly connected, Ethernet0
E 192.168.17.0 [140/1] via 192.168.16.2, 00:00:52, Ethernet0
E 192.168.18.0 [140/4] via 192.168.16.3, 00:00:52, Ethernet0
E 172.20.0.0 [140/1] via 192.168.16.4, 00:00:52, Ethernet0
E 172.16.0.0 [140/4] via 192.168.16.3, 00:00:52, Ethernet0
E 172.17.0.0 [140/1] via 192.168.16.2, 00:00:52, Ethernet0
E 172.18.0.0 [140/4] via 192.168.16.3, 00:00:52, Ethernet0
172.19.0.0 255.255.255.0 is subnetted, 1 subnets
C 172.19.1.0 is directly connected, Loopback0
Shemp#其次，每个由EGP宣告的网络的距离值都比例1-5 Update消息中显示的距离大1，这是因为与RIP路由算法一样，Cisco的EGP进程将所有距离值都加1。
EGP的根本问题是无法检测路由环路。由于EGP使用的距离值存在上限（255），因而有人可能会说，至少计数到无穷大也算是一种环路检测机制。这一点在理论上没错，但这种高极限值加上轮询间隔，使得计数到无穷大变得毫无实用意义。举例来说，假设轮询间隔为180秒，那么EGP对等体需要花费将近13小时才能计数到无穷大。正如RFC 904所说的那样“如果拓扑结构不遵循末梢网络的规则……那么外部网关协议将无法提供足够的拓扑结构信息来防止环路”。
因此，EGP必须运行在一个设计良好的无环路拓扑结构上。虽然在1983年的时候这并不是一个问题，因为那时的EGP仅仅被设计用来将末梢网关连接到ARPANET骨干网上，但当时的EGP设计者就已经预见到了这种拓扑结构限制所带来的问题将会很快显现出来。组成Internet的自治系统需要逐渐演变为几乎无结构化（或者说完全无结构化）的网状拓扑，此时很多自治系统都可以充当其他自治系统的转接系统。
随着NSFnet的出现，EGP的局限性变得日益明显。此时不仅出现了多个骨干网，而且还要考虑哪些流量可以穿越哪些骨干网等使用策略。由于EGP不支持这种复杂的策略路由，因而必须制定过渡解决方案（RFC 1092）。
EGP的另一个重要不足就是无法与IGP进行足够的互操作，以确定从一个网络到另一个网络的最短路由。例如，EGP的距离无法可靠地转换为RIP的跳数。如果EGP的距离导致跳数超过15跳，那么RIP将宣告网络不可达。EGP的其他不足之处还包括在大量网络之间传播信息时容易失败，而且还容易有意或无意地传播错误网络信息。
最后（当然也很重要），EGP无法及时宣告网络的变化情况。邻居获取进程很慢，而且网络变化的宣告过程也缓慢不堪。例如，EGP仅在无法收到特定路由的连续6条更新消息时，才宣告该路由可不用。再加上EGP的默认更新间隔为180秒，因而EGP路由器需要花费18分钟时间才能宣告路由不可用，此后才停止在更新消息中包含该路由。距离故障网络仅仅3跳之外的路由器则需要花费54分钟时间才能宣告该路由中断！ 因而大家有时可能会将根本不存在的路由误认为出了问题（EGP自身固有的问题除外）。
虽然人们试图创建EGPv3，但毫无成效。最后EGP仍然被彻底废弃，取而代之的是全新的AS间协议——BGP。目前，外部网关协议（EGP）不仅是一个协议的名称，而且还是一类协议的名称，所有衍自EGP概念的协议都被称为EGP。但尽管如此，当今的自治系统以及AS间的路由当中仍然能够看到传统EGP的身影。
由于EGP只是一种可达性协议，而不是一种真正的路由协议，因而对EGP所做的大量增强性尝试都失败了。将EGP改造成路由协议将使其失去本来面目，也就无法再简单地称之为EGP增强版本。这将是一个完全不同的协议。果真如此的话，那么就可能需要重新设计一个全新的域间协议：这将是一个真正的路由协议，能够精确区分去往同一个目的地的多条路由，能够避免出现环路，而且还能与IGP协作计算距离。
该AS间路由协议就是由1989年RFC 1105首次引入的BGP。BGP的第一个版本由一年之后的RFC 1163进行更新，后来又在1991年由RFC 1267进行了再次更新。为了表示这三次更新情况，后来人们习惯上将这三个版本分别称为BGP-1、BGP-2、BGP-3。
当前的BGP版本BGP-4是由1995年RFC 1771规定的。BGP-4与前面的几个版本有了显著区别，最重要的区别在于BGP-4属于无类别协议，而早期的版本则属于有类别协议。出现这一根本性改变的源动力直指外部网关协议存在的根因：保持Internet路由的可管理性和可靠性。为此创建了CIDR（Classless InterDomain Routing，无类别域间路由），CIDR最初由1993年RFC 1517引入，同一年由RFC 1519确定为标准建议，后来由RFC 1520进行修订，为了支持CIDR又创建了BGP-4。有关CIDR（读作“cider”）的详细信息将在本章后面进行讨论。
在BGP-4成为BGP的正式商用版本之后的十多年时间里，大多数时候都要加上版本号来正确引用该协议，本书的第一版也是如此，反映了当时本书的写作时代。考虑到BGP的前三个版本早已消失在历史的长河中，目前运行的BGP几乎都毫无例外地是BGP-4（当然也不否认，某些场合仍有可能在勉力运行着一种或两种早期的BGP版本），因而现在完全可以放心地去掉版本号。在21世纪谈论BGP的时候，指的就是BGP-4，不可能是任何其他版本。
注：
为了反映业界的共识，12.0(6)T之后的IOS仅支持BGP版本4。对于之前的IOS版本中的BGP实现来说，既可以在每个邻居之间进行自动协商（默认），也可以手工设置版本号。
与EGP一样，BGP也为每个BGP对等体建立一条唯一的、基于单播的连接。为了提高对等连接的可靠性，BGP使用TCP（端口179）作为底层传送机制。由于将确认、重传和序列化等工作交由TCP层处理，因而BGP的会话维护以及更新机制也得到了大幅简化。由于BGP建立在TCP（一种点到点协议）之上，因而需要为每个对等体都建立一条独立的点到点会话。此外，由于邻居之间的MD5认证也基于TCP，因而BGP得到了进一步简化。
BGP是一种距离矢量协议，每个BGP节点都依赖下游邻居从路由表中传递路由；BGP节点基于它们所宣告的路由进行路由计算，并将计算结果传递给上游邻居。但是，其他距离矢量协议都以单一数值来量化距离，用来表示跳数或全部接口时延之和以及最低带宽（对于EIGRP来说），而BGP却使用数据包到达特定目的地所要经过的自治系统列表（以AS号来表示）（见图1-4）。由于该列表完全描述了数据包所要经过的路径，因而为了与其他传统距离矢量协议相区别，也将BGP称为路径矢量路由协议。与BGP路由相关联的AS号列表则被称为AS_PATH。AS_PATH是与每条路由相关联的路径属性之一。有关路径属性的详细内容将在第2章进行介绍，有关路径属性的使用方式将在第3章到第5章进行介绍。
注：
虽然BGP依赖直接对等体来共享路由信息并成为路由分布式计算的一部分（与其他距离矢量协议相似），但AS_PATH列表提供的去往目的地的列表看起来更像是一种链路状态协议（与传统的距离矢量协议相比）。
图1-4 BGP根据被称为AS_PATH属性的AS号列表来确定最短无环路AS间路径
前面曾经说过，EGP不是一种真正的路由协议，因为它没有一个成熟的算法来计算最短路径，而且也无法检测路由环路。与此相反，AS_PATH属性使得BGP在这两方面都同时满足了作为路由协议的要求。首先，可以通过最小AS号来确定最短的AS间路径。图1-4中的AS7收到两条去往207.126.0.0/16的路由，其中一条路由的AS跳数为4，另一条路由的AS跳数为3，因而AS7将选择最短路径（4,2,1）[4]。
利用AS_PATH属性还能很容易地检测出路由环路。路由器在接收到路由更新后，如果在AS_PATH中发现了自己的本地AS号，那么路由器就知道出现了路由环路。图1-5中的AS7向AS8宣告了一条路由，AS8将该路由宣告给了AS9，AS9又将该路由宣告回了AS7。AS7发现自己的AS号在AS_PATH中，因而拒绝接受该更新，从而避免了潜在的路由环路问题。
图1-5 如果BGP路由器发现自己的AS号位于其他AS路由器宣告的路由的AS_PATH中，则拒绝该更新
虽然AS_PATH给出了去往目的地的路径上的详细自治系统信息，但BGP并不显示每个AS中的详细拓扑信息。由于BGP看到的仅仅是一个自治系统树，而IGP看到的是AS内部的拓扑情况，因而也可以说BGP比IGP看到的是更高层次的Internet视图。由于该更高层次的视图与IGP看到的视图并不兼容，因而IOS维护了一个独立的路由表（更准确的说法应该是RIB[Route Information Database，路由信息库]）以承载BGP路由。例1-7给出了命令show ip bgp显示的典型BGP路由表信息[5]。
例1-7 命令show ip bgp显示的BGP RIB
route-views.oregon-ix.net>show ip bgp
BGP table version is 121115564, local router ID is 198.32.162.100
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 3.0.0.0 217.75.96.60 0 0 16150 3549 701 703 80 i
* 194.85.4.55 0 3277 3216 3549 701 703 80 i
* 64.125.0.137 124 0 6461 701 703 80 i
* 213.200.87.254 10 0 3257 1239 701 703 80 i
* 203.62.252.186 0 1221 4637 703 80 i
* 66.185.128.48 504 0 1668 701 703 80 i
*> 4.68.1.166 0 0 3356 701 703 80 i
* 154.11.11.113 0 0 852 1239 701 703 80 i
* 144.228.241.81 4294967294 0 1239 701 703 80 i
* 193.0.0.56 0 3333 3356 701 703 80 i
* 4.0.0.0/9 217.75.96.60 0 0 16150 3549 3356 i
* 194.85.4.55 0 3277 3267 3343 25462 3356 3356 i
*> 4.68.1.166 0 0 3356 i
* 129.250.0.171 1 0 2914 3356 i
* 144.228.241.81 4294967294 0 1239 3356 i
* 208.51.134.254 53 0 3549 3356 i
* 134.222.85.45 0 286 3549 3356 i
* 4.0.0.0 217.75.96.60 0 0 16150 3549 3356 i
* 194.85.4.55 0 3277 3267 3343 25462 3356 3356 i
* 64.125.0.137 124 0 6461 3356 i
*> 4.68.1.166 0 0 3356 i
* 4.21.41.0/24 217.75.96.60 0 0 16150 3549 2914 16467 36806 i
* 194.85.4.55 0 3277 3216 3549 2914 16467 36806 i
* 64.125.0.137 124 0 6461 2914 16467 36806 i
* 144.228.241.81 4294967294 0 1239 2914 16467 36806 i
* 203.181.248.168 0 7660 2516 209 2914 16467 36806 i
*> 129.250.0.11 8 0 2914 16467 36806 i
* 4.23.112.0/24 217.75.96.60 0 0 16150 174 21889 i
* 194.85.4.55 0 3277 3267 3343 25462 174 21889 i
* 64.125.0.137 120 0 6461 174 21889 i
* 65.106.7.139 3 0 2828 174 21889 i
--More--虽然例1-7中显示的BGP路由表与利用命令show ip route显示的AS内部路由表有些不同，但其中的信息基本一致。BGP路由表显示了目的网络、下一跳路由器以及用于选择最短路径的度量值。有关Metric、LocPrf和Weight列的信息将在第2章进行介绍，现在关心的是Path列，该列列出的是每个网络的AS_PATH属性。
请注意，对于每个目的网络来说，表中列出了多个下一跳。与AS内部路由表仅列出当前在用路由不同的是，BGP RIB列出了所有已知路径。最左列的*（有效）后紧跟一个>，表示该路径是路由器当前使用的路由，该最佳路径是拥有最短AS_PATH的路径。如果存在多条拥有等价路径的路由（见例1-7），那么路由器就必须具备相应的规则来确定最佳路径。有关路径确定的进程将在第2章进行讨论。
如果去往特定目的端时存在多条并行等价路径（见例1-7），那么IOS的默认BGP实现将仅选择一条路径。这一点与其他IP路由协议不同，其他IP路由协议在默认情况下是在这4条等价路径之间做负载均衡。与其他IP路由协议一样，命令maximum-paths的作用是更改并行路径的默认最大值，取值范围是1～16。有关负载均衡的详细内容将在第3章进行讨论。
两个邻居在首次建立BGP对等连接时，会交换各自的全部BGP路由表，之后仅交换增量部分的路由更新。也就是说，仅当网络出现变化时才相互交换路由信息，并且仅交换变化信息。由于BGP并不使用周期性的路由更新机制，因而对等体之间必须交换Keepalive（保持激活）消息，以维护该对等连接。IOS的默认保持激活间隔为60秒（RFC 4271并没有指定标准的保持激活间隔）。如果对等体在3个间隔时间内均未收到保持激活消息，那么该对等体将宣告其邻居中断。可以通过命令timers bgp修改该时间间隔。
前面曾经说过，与IGP相比，BGP是从更高的层次上看待整个互联网络：IGP关注的是穿越一台台路由器的跳数，而BGP关注的则是穿越一个个自治系统的跳数。BGP比IGP层次更高的另一个表现是：与子网存在末梢（stub）子网与转接（transit）子网之分一样，自治系统也存在末梢AS与转接AS之分。
前面在讲述EGP的核心及末梢自治系统时就已经谈到上述概念了（见图1-2）。EGPd核心AS就是转接AS，负责将数据包从一个末梢AS传送到另一个末梢AS。区别在于为了规避环路问题，EGP只有一个核心AS，而BGP可以拥有多个转接自治系统。以图1-4为例，自治系统2、3、4、5和6都是源自AS7且去往AS1的数据包的转接自治系统，但这并不意味着图中的AS1和AS7就是末梢自治系统，因为AS7和AS1还可能是从AS4去往AS6的数据包的转接自治系统。
一般来说，路由进/出末梢AS都非常简单，相应的末梢AS的BGP配置也很简单。事实上，很多时候甚至都不需要BGP。有关末梢AS除BGP之外的其他替代方案将在第2章进行讨论。
BGP的实际作用只有在配置转接自治系统时才能真正体现。虽然BGP协议本身比较简单（比EIGRP、OSPF或IS-IS要简单得多），但每条路由都关联了大量路径属性，因而可以通过一组强大的策略工具来控制这些路由。有了路径属性以及利用这些路径属性的工具之后，就可以灵活第配置路径策略。这里所说的路由策略指的是对路由施加某种优先级规则，从而改变路由的默认行为。与优先级相关的一些例子如下：
有关路径属性及路由策略的相关信息将在第2章进行介绍，第4章则介绍创建路由策略的工具及步骤，第5章将解释与BGP扩展相关的工具。
由于BGP支持多种地址簇，因而BGP不仅仅是一种单播IP路由协议，而且是支撑大量IP网络服务的基础协议。这些网络服务不但可以跨越转接自治系统，而且还可以延伸到末梢自治系统中。为BGP提供这些增强型能力的机制就是MP-BGP（Multiprotocol BGP，多协议BGP），相关内容将在第6章进行讨论。
与前面讨论过的EGP末梢自治系统与转接（核心）自治系统概念一样，EGP协议也引入了内部邻居与外部邻居的概念。也就是说，如果EGP进程与本AS内的邻居建立对等关系，那么该邻居就是内部邻居，如果该邻居位于其他AS中，那么就是外部邻居。
BGP也使用相同的概念：如果BGP会话是在不同自治系统内的两个邻居之间建立的，那么该会话就是EBGP（External BGP，外部BGP）会话。如果BGP会话是在同一个自治系统内的两个邻居之间建立的，那么该会话就是IBGP（Internal BGP，内部BGP）会话（见图1-6）。
由于每个AS通常都拥有多台路由器，因而在AS内部通过BGP宣告信息时始终都要用到IBGP。从图1-6可以看出，AS1中的路由器利用EBGP及IBGP会话可以将路由宣告给AS3中的路由器。从习惯上来说，IBGP会话通常与转接AS（见图1-6中的AS2）相关联，末梢AS一般仅在一台或多台边界路由器上运行EBGP，并通过IGP路由传送/接收边界路由器的数据包。但是随着越来越多的服务（如基于MPLS的VPN以及IP多播）需要用到MP-BGP，末梢AS也开始逐渐出现了IBGP。
图1-6 不同AS中的邻居通过EBGP进行通信，而同一AS中的邻居则通过IBGP进行通信
前面曾经说过，BGP不仅将AS_PATH用作AS的跳数度量，而且还利用AS_PATH来避免环路：如果路由器发现自己的AS号位于AS_PATH列表中，那么就丢弃该路由。但这一点却给IBGP带来了一些有有趣的问题。
以图1-7为例，假设某路由需要从AS1经AS2传递给AS3，穿越AS2的物理路径是RTR1、RTR2与RTR3等三台路由器。如果这三台路由器在传递路由时都将自己的AS号添加到AS_PATH列表中，那么就会出现以下两个问题。
图1-7 从AS1发送给AS3的路由宣告在物理路径上必须穿越AS2中的3台路由器
图1-8 如果AS2中的每台路由器都将自己的AS号添加到AS_PATH中，那么AS3中的
路由器将会误认为该前缀相距4个AS跳，而不是2个AS跳
图1-9 如果RTR1将自己的AS号添加到了AS_PATH中，那么RTR2（位于同一AS中）
将会误认为出现了环路并丢弃该路由
为了解决上述问题，IBGP规定了如下特殊规则：
仅当路由器将路由发送给EBGP邻居时，才将自己的AS号添加到该路由的AS_PATH中。如果发送给IBGP邻居，那么就不向AS_PATH添加自己的AS号。
图1-10显示了该规则的效果：由于AS2中的路由器不会在AS_PATH列表中看到自己的AS号，因而这些路由器将不会丢弃该路由，AS3中的路由器也能正确地确定距离前缀A的AS跳数。
图1-10 通过仅在将路由发送给EBGP邻居时才向AS_PATH中添加AS号
来解决图1-8和图1-9中的问题
虽然该规则解决了图1-8和图1-9的问题，但是又引入了其他问题。虽然检测AS_PATH列表中的AS号是BGP检测与避免路由环路的方法，但AS_PATH对于单个AS范围来说却毫无意义。因此，如果在AS内部出现了路由环路，那么该怎么办呢？该如何避免这类路由环路呢？
为了解决这个问题，还必须重新审视EGP。由于EGP没有环路避免机制，因而唯一的解决方案就是确保设计一个无环路拓扑结构。 这一点也是OSPF和IS-IS采取层次化区域拓扑结构的原因之所在（如本书第一卷所述）。由于SPF树（是链路状态协议发现环路的手段）不会跨越区域边界，因而能够实现区域间无环路拓扑结构。
这种方法也是解决IBGP路由环路问题的解决方案：确保IBGP对等会话不出现环路的条件就是构建无环路拓扑结构。该解决方案的一个关键点就是BGP会话运行在TCP之上，TCP是一种单播点到点协议（可以在一定程度上避免潜在的环路风险），而且不要求BGP会话双方物理相连。因而对于前面的示例网络来说，虽然穿越AS2的路径将穿越三台路由器，但仍然可以在边界路由器之间直接建立IBGP会话（见图1-11），图中的IBGP会话虽然在物理路径上穿越了RTR2，但是在逻辑上该会话仅存在于RTR1与RTR3之间。
图1-11 通过仅在边界路由器之间建立IBGP会话来创建无环路IBGP拓扑结构
不过到现在还没有完全解决IBGP的所有问题。为了更好地理解接下来要说的问题，假设将通过图1-11中的EBGP和IBGP会话传送去往前缀A的路由。图1-12给出了RTR3的相应路由表项信息。由于该路由表项是通过RTR1的路由宣告创建的，因而RTR1被标示为去往该目的地的下一跳。而到达AS2中的RTR1的下一跳是RTR2，因而图中也列出了该路由表项。
图1-12 RTR3的路由表显示RTR1是去往前缀A的下一跳，并且RTR2是去往RTR1的下一跳
从图1-13可以很容易地看出问题之所在。假设图中数据包的目的地址属于前缀A，那么就会从AS3转发到AS2。图1-13的处理过程如下。
1．RTR3收到该数据包之后，将查找其目的地址并发现下一跳是RTR1。
2．由于RTR3与RTR1并不直接相连，因而RTR3必须进行第二次路由查找，以确定如何将数据包转发给下一跳地址。
3．由于去往RTR1的下一跳是RTR2，因而将该数据包转发给路由器RTR2。
4．由于传送路由的IBGP会话显示该路由直接从RTR1到达RTR3，因而RTR2没有去往前缀A的路由表项，因而RTR2将丢弃该数据包。
因此，虽然图1-11显示的逻辑拓扑结构实现了无环路路由交换，但是并没有共享该数据包将要使用的足够的实际路径信息，因而无法成功转发该数据包。从这个问题可以看出，建立IBGP会话时必须考虑以下两个层面的信息：
图1-13给出了路由器执行递归查询的过程：首先查找去往该数据包目的地址的路由，如果下一跳地址并不直连，那么就需要再次执行路由查询，以找到去往下一跳地址的路由。由于IGP通常都是逐跳路由，因而递归查询对于IGP来说没有问题，但是对于IBGP来说却是一个问题。
为了解决图1-13所显示的问题，对于数据包将要经过的路径上的所有路由器来说，它们的路由表中必须拥有足够的信息，必须知道如何转发该数据包。一种解决方案就是将所有学自EBGP邻居的路由都重分发到IGP中[6]。图1-11中的RTR1在收到来自AS1的前缀A的路由信息之后，除了将该路由信息宣告给RTR3之外，还要将该路由信息重分发到本地IGP中。此后当数据包转发到RTR2之后（见图1-13），RTR2就有了一条通过IGP从RTR1学到的关于前缀A的路由表项，该路由表项显示RTR1是该前缀的下一跳。
图1-13 利用图1-12显示的路由表项，RTR3将去往前缀A的数据包转发给RTR2，
但RTR2没有去往前缀A的路由，因而RTR2将丢弃该数据包
虽然将BGP路由重分发到本地IGP在理论上看起来很好，但是在实际应用中却很糟糕（具体原因将在第3章讨论）。简而言之，将BGP路由重分发给IGP存在以下两个问题。
经实践证明，大多数场合下的最佳实践就是让BGP将学到的路由保持在BGP中。如果必须将这些路由分发给AS中的路由器以解决图1-13的问题，那么就通过IBGP来分发这些路由（见图1-14）。通过IBGP有效分发路由的实践方式要求单个AS内的所有BGP路由器之间都必须建立全网状的IBGP会话。虽然为了解决扩展性问题，还需要对这种实践方式做一些调整（具体将在第5章进行讨论）。但是在学到第5章之前，读者完全可以将这种全网状的IBGP会话部署方式列入自己的最佳实践。
图1-14 IBGP会话不仅包含AS边界路由器，还包含所有可能利用从外部学到
的目的地址转发数据包的路由器
图1-14的逻辑拓扑结构又带来了环路避免问题。到目前为止使用的物理拓扑结构都很容易理解，但大多数自治系统的实际内部架构却非常复杂，以图1-15为例。图中的逻辑BGP拓扑结构就与自治系统的物理拓扑结构大相径庭。虽然EBGP会话（以穿越AS边界的箭头线表示）与外部物理链路一致，但全网状的IBGP会话却显得非常复杂。需要记住的是，每个IBGP会话都必须穿越某些物理链路。例如，图1-15中RTR5与RTR6之间的直接IBGP会话就实际穿越了RTR2和RTR3。
那么该如何避免复杂拓扑结构中的BGP路由环路问题呢？需要再增加一条IBGP规则：
始终不要将学自内部邻居的路由发送给其他内部邻居。
建立IBGP全网状连接的目的是确保AS内的所有路由器都拥有将数据包转发到正确下一跳的路由信息。假设图1-15中的RTR6在其AS外部链路上收到了一个数据包，并且路由查找显示RTR7是下一跳，那么该数据包必须通过RTR2、RTR3和RTR5的路径才能到达该下一跳。而IBGP会话可以确保任一台路由器在学到来自外部邻居的路由之后，都能将该路由信息直接转发给AS内的所有路由器。任一台路由器都不用再将该路由信息转发给AS内的其他路由器。此外，如果没有将学自内部邻居的路由信息传送给其他内部邻居，那么也就不会存在任何路由环路。
图1-15 IBGP会话的全网状连接要求导致BGP拓扑结构与实际的物理拓扑结构大相径庭
图1-15中的拓扑结构拥有5条外部连接。虽然图中并没有给出每条连接的详细去向信息（可能每条连接都连接了一个不同的自治系统，也可能连接的都是同一个AS，也可能是这两种情况的折中），但是从数据包自RTR6进入AS并从RTR7离开AS可以看出，这是一个转接AS。
拥有多条外部连接的AS（见图1-15）就是多归属AS。根据定义，数据包穿越AS时，转接AS必须是多归属AS。本节将详细介绍各种AS类型的多归属情况。
转接AS通常都是服务提供商网络（负责将基本的Internet连接或语音及视频服务传送给其连接的客户）或运营商网络（专门为较小的服务提供商网络提供地理覆盖广阔的骨干网）。不过转接AS也可能是大型商业、政府或教育机构的骨干网。
转接网络通常存在以下三类外部连接。
对于特定的转接AS来说，有时可能是上述三种对等互联类型的子集。例如，某些客户可能愿意比其他客户多支付一定的费用以获得更为严格的SLA（Service-Level Agreement，服务等级协议），要求服务提供商必须更加关注这类高价值客户，在网络出现拥塞或者部分网络出现中断的情况下，为这类客户的流量赋予更高的优先级。与此相似，有时也可能因为某些协议或预估价值在建立对等互联时采取付费的专用对等互联方式。相应地，经由这些对等互联点的路由的价值就比经由其他免费获得的公共对等互联点的路由价值高。在前面所说的两种情况下，都要求网络运营商具备相应的工具和方法，能够灵活地调整AS内的流量优先级并改变默认的路由行为。
虽然转接AS具备多归属特性是显而易见的（否则也不可能成为转接AS），但多归属特性对于末梢AS也是非常普遍的。如果末梢AS小到不需要多归属，也就是说仅通过单条链路连接更高层级的AS，那么一般也不需要部署BGP。此时在连接两端部署静态路由，不但配置简单，而且管理起来也更加安全。以图1-16为例，图中的末梢AS只有一条连接去往转接AS，此时没有在对等互联路由器之间运行BGP，而是在AS65501中的RTR1上静态配置了一条默认路由，并通过本地IGP在整个AS内部宣告该静态路由。AS内找不到与数据包目的地址相匹配的路由的所有路由器都将匹配该默认路由，并将数据包转发给RTR1，再由RTR1将数据包转发给AS65510。
RTR2为AS65501中的前缀配置了静态路由并通过IBGP在AS内宣告这些静态路由。AS内的其他边界路由器通过IBGP学到这些前缀之后，利用EBGP将这些路由（更好的方式是宣告这些前缀的聚合路由）宣告给各自位于其他AS中的外部对等体。图1-16中的静态路由方式能够严格控制在每个AS中宣告其他AS的哪些信息，而不存在通过管理边界意外泄露非期望前缀的风险。
末梢AS采取多归属方式的主要理由如下：
图1-16 静态路由通常是单归属AS的更好选择（与BGP相比）
图1-17给出了一个简单的防范链路或接口故障的多归属配置示例。该方案配置了两条链路，每条链路都通过一个独立的接口连接到外部邻居上，从而在任一条链路或任一个接口出现故障时，AS65501都能有一条路径去往转接提供商的AS。
图1-17 简单的多归属配置方案可以防止因边界路由器上的一条链路或接口出现故障后的接入中断风险
虽然只要简单地在两台边界路由器之间部署更多的链路就能提高链路或接口的故障冗余能力，但是如果图1-17中的任一台边界路由器出现故障，那么接入仍然会中断。该配置方案存在的另一个问题就是图中显示的两条链路（如果连接到同一台物理路由器上）很可能位于同一条线缆或同一条管道中，那么线缆或管道被挖断都会导致这两条链路同时出现中断[9]。
图1-18给出了优化后的拓扑结构。此时的AS65501不会再因为任一条链路、接口或路由器故障而导致接入中断。如果两台路由器位于不同的相距较远的物理局点，使得这两台路由器不可能同时出现灾难问题，那么就能进一步提升该配置方案的冗余能力。
图1-18 将冗余链路分布到冗余路由器上可以进一步降低接入中断的风险
对于图1-18中的末梢AS来说，如果其单一转接提供商出现网络中断，那么该末梢AS依然会出现接入中断问题。整个提供商网络偶尔出现全面故障的可能性是存在的，此时最可能的故障原因就是BGP策略配置错误（第4章将详细讨论BGP策略配置大意而产生的可能风险）。图1-19给出的优化拓扑结构不但防范了末梢AS可能存在的链路、接口以及路由器故障风险，而且还防范了可能存在的ISP故障风险。此时的末梢AS连接了三个不同的转接提供商，如果其中的一个或两个提供商的转接AS出现故障后，至少还有一条路径进出该末梢AS（假设所有的转接提供商都拥有上行对等连接，能够提供所有的Internet路由）。
图1-19 将冗余链路分布到冗余自治系统上可以降低因提供商网络
故障而导致的接入中断风险
图1-20给出了同时采用冗余链路、冗余路由器以及冗余转接提供商在内的多种冗余机制后的优化拓扑结构，该拓扑结构提供了极为可靠的接入能力。不过，随着接入可靠性级别的不断提升（见图1-17至图1-20），相应的网络投资、连接成本以及维护成本和维护复杂性都大幅提高，因而在现实中很少采用图1-20所示的理想冗余方案。需要在可接受的故障风险与成本之间做出平衡：图1-16的成本最低但风险最高，图1-20的成本最高但风险也最低。
图1-20 同时采用冗余链路、冗余路由器以及冗余转接提供商在内的多种
冗余机制之后几乎可以将接入风险降至为零
多归属还能为地域范围广阔的AS（如跨越美国大多数州并与纽约的ISP对等互联的AS）提供本地Internet连接性。假设某数据包源自洛杉矶且外部目的地址靠近圣地亚哥，那么该数据包就必须穿越内部网络到达位于纽约的外部对等互联点，然后再穿越整个美国最终到达与源端相距不到100英里的目的端；返回的响应数据包也必须再次穿越整个美国，从圣地亚哥到纽约再到洛杉矶。这种流量模型不但浪费了大量网络资源，而且会产生不必要的时延和无法预料的时延变化（抖动），从而给时间敏感型应用（如语音和视频）带来严重问题。此外，这种流量模型还会在一定程度上降低网络的可靠性：数据包传送的距离越远，遇到网络故障的概率就越高，丢失的可能性也越大。
图1-21给出了一个末梢AS示意图，其内部拓扑结构跨越了美国的大多数州。该AS不再是单个ISP对等互联点，而是在全国范围内分布了5个对等互联点。源自国内任意位置的数据包都被路由到距离源端最近的Internet对等互联点（最近的出口点）。如此一来，前面示例中提到的数据包（源端是洛杉矶，目的端是圣地亚哥）就会从洛杉矶对等互联点离开本AS，返回流量也将从同一个互联点进入本AS，从而大大降低了会话时延及抖动。
图1-21 多归属方式可以为地域范围广阔的AS提供本地连接性
图1-21中的EBGP对等体可能位于同一个AS中，即去往同一个ISP，也可能每个对等体均去往不同的ISP以实现ISP的冗余性（见图1-19）。大多数真实的网络环境可能是这两种情况的混合体。例如，洛杉矶、芝加哥和亚特兰大可能与Level 3 Communications互联，而达拉斯和纽约则与Verizon互联。
多归属到多个ISP不仅能够提供ISP冗余能力，保护自己的网络免受单一提供商系统范围故障导致的网络中断，而且还能实现提供商的独立性。如果使用的是单一ISP，现在希望更改为另一个ISP（原因是对当前ISP的可靠性、性能或价格不满意，也可能是其他ISP提供了更好的服务特色或者为经常访问的目的地提供了更好的网络连接），那么更改过程将非常复杂，代价也很高。如果与多个ISP都有对等连接，并且希望更改其中的一个ISP，那么更改过程将简单易行，因为网络可以在更改过程中通过其他提供商保持网络的连接性。
与多个ISP建立对等互联还存在一定的成本优势。不同的服务提供商在竞争用户时，可能会提供更加优惠的费率。如果连接了两家或多家ISP，那么任何一家ISP都不会冒着丢失客户的风险提高自己的费率（此外，如果连接了多家ISP，那么淘汰一家价格过高的ISP也更加容易）。
如果需要执行AUP（Acceptable Use Policies，许可使用策略）或企业策略，要求某些流量必须使用某个转接AS，其他流量必须使用另一个转接网络，那么也需要部署多归属机制。例如，军队或其他政府机构可能规定了严格的网络策略，要求敏感流量始终使用那些通过了严格安全审查的转接提供商。或者某个企业可能与多个相互之间存在竞争关系的合作伙伴都建立了对等互联，要求任一个合作伙伴的流量都不能穿透其他合作伙伴的网络。
与转接AS提供商需要具备相应的工具及方法来更改默认路由行为以满足不同对等互联的需求一样，多归属末梢AS的提供商也需要具备相应的工具及方法，避免自己的网络被所连接的AS无意间用作转接网络，或者为所连接的ISP施加不同的优先级，或者实现所需的AUP，这些就是路由策略所要完成的任务。
本书第一卷的后面章节曾经介绍了一些基本的部署路由策略的IOS工具：路由重分发、默认路由、路由过滤器以及最强大的IOS路由策略工具——路由映射。与IGP相比，BGP尤其适合部署路由策略，这是因为BGP提供了一组被称为路径属性的特性。可以利用策略工具来添加、更改或删除这些路径属性，从而影响各种不同的路由行为。前面已经遇到了一种BGP路径属性——AS_PATH，第2章将介绍其他基本的路径属性并解释这些路径属性的使用方式。第4章将以案例方式说明这些路由策略的配置方式，最后将在第5章和第6章介绍一些专用的路径属性及其使用方式。
多归属的主要好处是能够提供冗余性、实现路径的多样化并增加到外部对等体的带宽。如果部署多归属的主要目标是提供更多的带宽（一般是在两台路由器之间捆绑多条链路[见图1-17]），而且每条链路的带宽都相同，那么就可以在被捆绑的所有链路中完全均等地共享这些流量负载。
如果多归属的主要目的是提供冗余性，那么任一条链路的负载都必须低于冗余链路所承载的全部流量。以图1-18为例，图中两条外部链路的负载在通常情况下都应该低于链路带宽的50%。在这种情况下，当其中的一条链路出现故障导致需要将其正常流量重路由到另一条链路上时，该正常链路将能处理全部负载。如果网络运行正常时，每条链路的负载都平均达到了链路带宽的75%，那么故障条件下被重路由到正常链路的流量将达到链路带宽的150%，导致1/3的数据包都将被丢弃。
无论什么时候都可以在多条链路上承载相同的数据包，在所有链路上共享全部入站和出站流量负载，此时的拓扑结构既可以像图1-17那样简单，也可以像图1-20和图1-21那样复杂。对于后一种情形来说，不仅在链路上实现了负载共享，而且在ISP上也实现了负载共享。随着链路以及ISP多样性的增加，优选路由的多样性也在增多。也就是说，并不是所有链路以及ISP都承载完全相同的流量。
因此，不要期望在所有的链路上完全均衡地承载流量负载。一般都会更多地连接其中的某个ISP。这个ISP或者其上游提供商可能会比其他ISP拥有更强大的路由器、更好的物理链路或者更多的对等连接，或者这个ISP仅仅在拓扑结构上更靠近用户经常访问的大多数目的地。
需要注意的是，负载共享与负载均衡并不相同。负载均衡指的是打着有效利用带宽的名义，在所有外部链路上竭力维持完全相同的负载比例（通常大家都被误导了）。
这并不是说无法通过控制路由优先级的方式在所有外部链路上实现流量的完全均分（需要花费大量的时间和精力），但问题是为了实现负载均衡而强制让某些流量使用次优路由的话，很可能会劣化Internet的接入性能。大多数情况下需要做的就是尽可能地均等使用所有的ISP链路。此外，由于Internet目的地经常处于变化状态，经常调整策略将会大大提升维护成本。因此，即便网络流量的75%都在使用某条链路，而只有25%的流量使用另一条链路，也大可不必过于在意。因为多归属的主要目的是提高冗余性并提升路由效率，而不是实现负载均衡。
多归属可能会导致去往相同目的端且来自相同源端的流量使用不同的路径进入和离开AS（因而很难预测）。这种路径多样性在外部链路都比较近的情况下没有什么问题，但是随着外部链路的距离越来越远，相应的潜在问题也就越来越突出。
图1-22中的AS与两个ISP（分别位于圣何塞和波士顿）建立了对等互联，这两个ISP在芝加哥的IXP中也建立了对等互连，并且AS65501利用内部链路经丹佛将其东海岸办事处与西海岸办事处连接在一起。此外，边界路由器将默认路由宣告到本AS中，内部路由器在找不到明细路由时将选择该默认路由。
从图中可以看出，西海岸的路由器发送了一个数据包。该数据包的目的端连接在位于东海岸的ISP2上，源端路由器为该目的端选择了默认路由，并且圣何塞的边界路由器被选为该默认路由的最近下一跳，波士顿的边界路由器被看做是次优路由。因此出站流量将首先经过ISP1，然后穿越芝加哥的IXP到达ISP2，最后转发给目的端。
目的路由器拥有两条去往AS65501的路由，分别经由ISP2的波士顿路由器和芝加哥的对等互联路由器，最终为去往源端路由器的响应数据包选择了经由波士顿路由器的最短路由。该路径将穿越AS65501的内部链路，因而源端路由器与目的端路由器之间的往返路径是不对称的。
图1-22 如果多归属AS的的外部对等互联点在地域上相距较远，那么就会出现不对称流量流
出现这种流量模型的典型原因是路由器选择的是默认路由。因为这些路由器没有关于其路由域外部目的端的明细路由或者不知道到达目的端的实际距离，它们唯一的路由选择标准就是宣告默认路由的最近的路由器。
出现不对称流量的主要原因如下。
BGP可以解决这类不对称路由问题（见图1-22）。如果AS65501在圣何塞和波士顿的边界路由器都与各自的ISP对等体建立了EBGP会话，那么它们就能学到去往图示目的端的路由。此后如果源端路由器学到了这两条路由，那么就能确定去往目的端的最短路径应该是经由波士顿的边界路由器，而不是经由圣何塞的边界路由器。这样一来，源端与目的端的流量模型就对称了（见图1-23）。
不过BGP不仅仅能够提供做出更优路由选择的手段，而且其策略能力还能让用户根据自己的需要定义一条“更佳路由”（这条路由并不在路由协议默认定义的范围之内）。例如，假设需要部署一个“热土豆路由”策略，要求去往外部目的端的流量始终经由最近的AS出口点，以节约内部网络资源，但同时又希望尽可能地避免不对称路径问题（见图1-22）。
图1-23 BGP可以帮助AS内部路由器对去往外部目的端的路由做出更佳选择
此时就可以利用BGP修改波士顿边界路由器，宣告与源端路由器相关联的前缀，使得目的端路由器将经由圣何塞进入AS65501的路径视为去往源端路由器的优选路由（见图1-24）。影响其他AS选择进入己方AS的路由的具体技术将在第4章将进行详细讨论。
图1-24 BGP策略可以影响其他AS选择进入本地AS的路由的方式
较小的组织机构连接到ISP网络上时，一般都会向ISP申请IP地址空间，ISP分配的地址空间源自ISP的大地址池。通常将采用这种方式分配给终端用户的地址称为PA（Provider Assigned or Provider-Aggregatable，提供商分配的或提供商可聚合的）地址。
如果作为终端用户的组织机构多归属到多个ISP，并且该组织机构拥有其中某个提供商分配的PA地址空间，那么宣告该地址空间以正确路由入站数据包就会存在一定的问题。要想完全理解这个问题，就必须首先理解ISP获得地址块（称为CIDR[Classless Inter-Domain Routing，无类别域间路由]块）的方式以及ISP向用户分配其地址块的方式。下一节将在介绍完CIDR之后再回过头来分析多归属到多个服务提供商时存在的问题。
虽然自治系统以及外部网关协议的发明解决了20世纪80年代出现的Internet扩展性问题，但是到了20世纪90年代早期的时候，Internet又出现了一些新的扩展性问题。
为了解决上述问题，当时开发了CIDR这种短期解决方案。另一种短期解决方案就是NAT（Network Address Translation，网络地址转换），有关NAT的详细内容将在第10章进行讨论。这些解决方案的目的是为Internet架构师们争取尽可能多的时间，从而创造出一种新的IP版本，为可预见的未来提供足够的地址空间。最初将这种新IP版本称为IPng（IP Next Generation，下一代IP），后来最终演变为具有128比特地址格式的IPv6[10]。但有趣的是，CIDR和NAT取得了巨大的成功，以至于时至今日很少再有人像当初那样迫切地希望将网络迁移到IPv6。
CIDR只是一种利用Internet分层架构的地址汇总方案，利用有类别的地址分配方式强行地址增加人为的边界。因而在进一步讨论CIDR之前，有必要先回顾一下汇总以及无类别路由问题。
汇总（Summarization）或路由聚合（Route Aggregation）（详见本书第一卷）指的是用一个较不精确的地址来宣告一组连续的地址。汇总/路由聚合的本质就是减小子网掩码的长度直至屏蔽所有被汇总地址的公共比特。例如图1-25中的4个子网（172.16.100.192/ 28、172.16.100.208/28、172.16.100.224/28和172.16.100.240/28）被汇总为单个聚合地址172.16.100.192/26。
图1-25 路由聚合将多个具有相同前缀的连续地址汇总为单个地址
许多将汇总视为一项艰难工作的网络新手都会惊诧于他们每天都得跟汇总打交道。除了一组连续主机地址的汇总地址之外，那什么是子网地址呢？举例来说，子网地址192.168.5.224/27就是主机地址192.168.5.224/32～192.168.5.255/32的聚合地址（当然，“主机地址”192.168.5.224/ 32是数据链路本身的地址）。汇总地址的关键特性就是掩码长度短于其所汇总的地址的掩码长度。最极端的汇总地址是默认地址0.0.0.0/0（通常写成0/0）。正如/0所表示的那样，此时的掩码已缩减至无任何网络比特，默认地址就是所有IP地址的聚合地址。
汇总操作还可以跨越地址的类别边界。例如，可以将4个C类网络（192.168.0.0、192.168.1.0、192.168.2.0以及192.168.3.0）汇总为一个聚合地址192.168.0.0/22。请注意，该聚合地址（使用了22位掩码）不再是一个合法的C类地址。因此，为了支持主类网络地址的聚合操作，整个路由环境都必须是无类别的。
无类别路由主要包括以下两个方面：
当今的网络已不再使用“有类别”IP路由协议（包括RIPv1、IGRP以及BGP-4之前的BGP版本）[11]。有类别路由也不再是当今绝大多数路由器的默认选项：IOS从11.3开始就将无类别路由作为默认选项，因而当前所有的IOS版本都是无类别路由。因此，可以在一定程度上将本节的内容视为历史介绍，不过仍然建议读者阅读本节的内容，因为这些知识对于理解最长匹配路由查找机制非常有用。
作为路由信息的一部分，无类别路由协议携带了每个被宣告地址的网络部分的描述信息。通常将网络地址的网络部分称为地址前缀。描述地址前缀时，既可以包含一个地址掩码（也就是指示该地址中有多少个前导比特是前缀比特的长度字段），也可以在更新中仅包含前缀比特（见图1-26）。常见的无类别IP路由协议包括RIP-2、EIGRP、OSPF、集成式IS-IS以及BGP-4[12]。
图1-26 无类别路由协议在路由宣告中包含前缀长度信息
有类别路由器在路由表中将目的地址记录为主类网络以及这些网络的子网。在执行路由查找时，有类别路由器首先查找主类网络地址，接着再在主类网络地址下的子网列表中查找匹配项。如果没有找到匹配项，那么就会丢弃数据包——即便存在像默认路由一样的路由。汇总与地址聚合技术对于现代网络设计中的CIDR以及扩展性来说必不可少，但对于有类别网络环境来说却是一个问题。
无类别路由器会忽略地址类别，并在路由表中为所有前缀查找“最长匹配”的目的地址。也就是说，对于任何给定的目的地址来说，无类别路由器都会选择匹配了最多地址比特（从左至右）的路由。例1-8中的路由表显示了一些按照可变子网方式划分后的IP网络。如果路由器是无类别路由器，那么该路由器就会尝试为每个目的地址都找到最长匹配项。
例1-8 该路由表包含了多个被可变子网划分后的IP网络
Cleveland#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is 192.168.2.130 to network 0.0.0.0
O E2 192.168.125.0 [110/20] via 192.168.2.2, 00:11:19, Ethernet0
O 192.168.75.0 [110/74] via 192.168.2.130, 00:11:19, Serial0
O E2 192.168.8.0 [110/40] via 192.168.2.18, 00:11:19, Ethernet1
192.168.1.0 is variably subnetted, 3 subnets, 3 masks
O E1 192.168.1.64 255.255.255.192
[110/139] via 192.168.2.134, 00:11:20, Serial1
O E1 192.168.1.0 255.255.255.128
[110/139] via 192.168.2.134, 00:00:34, Serial1
O E2 192.168.1.0 255.255.255.0
[110/20] via 192.168.2.2, 00:11:20, Ethernet0
192.168.2.0 is variably subnetted, 4 subnets, 2 masks
C 192.168.2.0 255.255.255.240 is directly connected, Ethernet0
C 192.168.2.16 255.255.255.240 is directly connected, Ethernet1
C 192.168.2.128 255.255.255.252 is directly connected, Serial0
C 192.168.2.132 255.255.255.252 is directly connected, Serial1
O E2 192.168.225.0 [110/20] via 192.168.2.2, 00:11:20, Ethernet0
O E2 192.168.230.0 [110/20] via 192.168.2.2, 00:11:21, Ethernet0
O E2 192.168.198.0 [110/20] via 192.168.2.2, 00:11:21, Ethernet0
O E2 192.168.215.0 [110/20] via 192.168.2.2, 00:11:21, Ethernet0
O E2 192.168.129.0 [110/20] via 192.168.2.2, 00:11:21, Ethernet0
O E2 192.168.131.0 [110/20] via 192.168.2.2, 00:11:21, Ethernet0
O E2 192.168.135.0 [110/20] via 192.168.2.2, 00:11:21, Ethernet0
O*E2 0.0.0.0 0.0.0.0 [110/1] via 192.168.2.130, 00:11:21, Serial0
O E2 192.168.0.0 255.255.0.0 [110/40] via 192.168.2.18, 00:11:22, Ethernet1
Cleveland#如果路由器收到一个目的地址为192.168.1.75的数据包，且路由表中存在多个与该地址相匹配的路由项：192.168.0.0/16、192.168.1.0/24、192.168.1.0/25和192.168.1.64/26，那么路由器将会选择192.168.1.64/26作为匹配项（见例1-9）。因为该路由项与目的地址匹配了26个比特：最长匹配。
例1-9 目的地址为192.168.1.75的数据包从接口S1被转发出去
Cleveland#show ip route 192.168.1.75
Routing entry for 192.168.1.64 255.255.255.192
Known via "ospf 1", distance 110, metric 139, type extern 1
Redistributing via ospf 1
Last update from 192.168.2.134 on Serial1, 06:46:52 ago
Routing Descriptor Blocks:
* 192.168.2.134, from 192.168.7.1, 06:46:52 ago, via Serial1
Route metric is 139, traffic share count is 1而目的地址为192.168.1.217的数据包则与192.168.1.64/26或192.168.1.0/25均不匹配。与该地址最长匹配的路由项应该是192.168.1.0/24（见例1-10）。
例1-10 路由器无法将192.168.1.217匹配到更精确的子网，因而将其匹配为网络地址192.168.1.0/24
Cleveland#show ip route 192.168.1.217
Routing entry for 192.168.1.0 255.255.255.0
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 10
Redistributing via ospf 1
Last update from 192.168.2.2 on Ethernet0, 06:48:18 ago
Routing Descriptor Blocks:
* 192.168.2.2, from 10.2.1.1, 06:48:18 ago, via Ethernet0
Route metric is 20, traffic share count is 1可以为目的地址192.168.5.3找到的最长匹配项是聚合地址192.168.0.0/16（见例1-11）。
例1-11 由于去往192.168.5.3的数据包无法匹配更精确的子网或网络，因而匹配聚合地址192.168.0.0/16
Cleveland#show ip route 192.168.5.3
Routing entry for 192.168.0.0 255.255.0.0, supernet
Known via "ospf 1", distance 110, metric 139, type extern 1
Redistributing via ospf 1
Last update from 192.168.2.18 on Ethernet1, 06:49:26 ago
Routing Descriptor Blocks:
* 192.168.2.18, from 192.168.7.1, 06:49:26 ago, via Ethernet1
Route metric is 139, traffic share count is 1最后，虽然目的地址192.168.1.1与路由表中的任何网络表项都不匹配（见例1-12），但路由器并不会丢弃这些数据包。这是因为例1-8显示的路由表中还包含了一条默认路由（在路由表中表述为gateway of last resort），因而路由器会将这些数据包转发给下一跳路由器192.168.2.130。
例1-12 虽然无法在路由表中找到192.168.1.1的匹配项，但是根据例1-8显示的路由表吗，路由器会将去往该地址的数据包被转发给默认路由的下一跳192.168.2.130（出接口为S0）
Cleveland#show ip route 192.169.1.1
% Network not in table例1-8中的路由表以及相关示例解释了最长匹配路由选择的另一个特性，那就是去往聚合地址的路由并不需要指向聚合地址中的每个成员。图1-27给出了例1-9到例1-12中的相关路由信息。
图1-27 例1-8所示路由表中的路由信息
下面分析一个聚合了全部子网的网络192.168.1.0/24。从图1-27可以看出，去往该网络地址的路由都将从接口E0向外转发数据包，但去往其中两个子网（192.168.1.0/25和192.168.1.64/26）的路由却指向了其他接口——S1。
注：
192.168.1.64/26实际上是192.168.1.0/25的成员，但这两个地址拥有不同的路由（都指向S1），暗示了这两个地址是由不同的上游路由器宣告而来的。
同样，虽然192.168.1.0/24也是聚合地址192.168.0.0/16的成员，但去往较不精确地址的路由是通过接口E1向外转发的，而最不精确路由0.0.0.0/0（是所有其他地址的聚合地址）则是通过接口S0向外转发的。根据最长匹配路由选择原则，去往192.168.1.0/25和192.168.1.64/26的数据包将从接口S1向外转发，而去往网络192.168.1.0/24的其他子网的数据包则从接口E0向外转发。如果数据包的目的地址以192.168开头（192.168.1除外），那么就从接口E1向外转发这些数据包，而那些目的地址不是以192.168开头的数据包则都从接口S0向外转发。
汇总是一种节约网络资源的有效工具，可以节约包括存储路由表所需的内存容量、网络带宽以及路由器传送和处理路由信息的能力在内的各种资源。此外，汇总还能通过“隐藏”网络的不稳定性来有效节约网络资源。
假设图1-28中存在一条翻动路由（flapping route）。这里所说的翻动路由指的是由于物理连接或路由器接口故障而出现不停Up/Down的路由。
图1-28 翻动路由使得整个网络变得不稳定
如果没有汇总机制，那么每次子网192.168.1.176/28出现Up/Down的时候，都必须将该路由翻动信息传送给企业网中的每一台路由器。这些路由器必须处理该信息并相应地调整各自的路由表。不过，如果路由器Nashville是通过单个聚合地址192.168.1.128/25来宣告所有的下行路由，那么无论哪个明细子网（包括192.168.1.176/28）出现了变化，路由器也不会宣告这些变化信息。此时的Nashville就是聚合点，即使被聚合的某些成员出现不稳定状况，聚合路由依然能够保持稳定。
汇总的代价就是牺牲了路由的精确性。从例1-13可以看出，如果图1-27中的路由器接口S1出现了故障，那么从该接口上的邻居学习到的路由将变得无效。但此时路由器并不会丢弃正常情况下从接口S1向外转发的数据包（如目的地址为192.168.1.75的数据包），因为此时的数据包将匹配次优路由192.168.1.0/24，从而从接口E0向外转发该数据包（可以与例1-9进行对比）。
例1-13 失效路由导致的转发行为变化
Cleveland#
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
%LINK-3-UPDOWN: Interface Serial1, changed state to down
Cleveland#show ip route 192.168.1.75
Routing entry for 192.168.1.0 255.255.255.0
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 10
Redistributing via ospf 1
Last update from 192.168.2.2 on Ethernet0, 00:00:20 ago
Routing Descriptor Blocks:
* 192.168.2.2, from 10.2.1.1, 00:00:20 ago, via Ethernet0
Route metric is 20, traffic share count is 1有时转发行为的变化在某些情况下可能是一个问题（取决于其余网络的状况）。下面接着讨论前面的示例。假设图1-27中的下一跳路由器192.168.2.2仍然有一条到达192.168.1.64/26的路由表项（经由例1-13中的路由器Cleveland）。可能的原因是路由协议暂未收敛，也可能是静态输入了该路由，那么就会产生路由环路问题。但是，某些通过Cleveland的E0接口可达的路由器可能会有一条去往子网192.168.1.64/26的“后门”路由，仅在主用路由（经Cleveland的S1接口）无效时才会使用该“后门”路由。此时去往192.168.1.0/24的路由就被设计为备用路由，那么例1-13显示的转发行为就属于有意为之。
从图1-29可以看出，失去路由精确性的网络可能会产生一些不同的问题。图中路由域1通过旧金山和亚特兰大的路由器连接到路由域2。本例中的路由域定义方式并不重要，重要的是路由域1中的所有网络都可以被汇总为地址172.16.192.0/18，路由域2中的所有网络都可以被汇总为地址172.16.128.0/18。
旧金山与亚特兰大的路由器并没有宣告单个子网，而是将汇总地址宣告到了两个路由域中。如果位于达拉斯子网172.16.227.128/26中的某台主机向位于西雅图子网172.16.172.32/28中的某台主机发送数据包，那么该数据包极有可能会被路由到亚特兰大（因为亚特兰大路由器是宣告路由域2汇总路由的最近路由器）。亚特兰大将数据包转发到路由域2，并最终到达西雅图。子网172.16.172.32/28中的主机发送响应信息时，则由西雅图将响应数据包转发到旧金山（是宣告汇总路由172.16.192.0/18的最近路由器）。
图1-29 在多台路由器宣告相同的聚合地址时，失去路由精确性就会出现问题
这里出现的问题就是两个子网之间的流量不对称问题：从172.16.227.128/26到172.16.172. 32/28的数据包使用的路径与从172.16.172.32/28到172.16.227.128/26的数据包使用的路径是不同路径。出现不对称路径的原因是达拉斯和西雅图路由器都没有去往对方子网的全部路由。它们仅知道去往宣告汇总路由的路由器的路由，因而必须基于这些路由转发数据包。换句话说，旧金山和亚特兰大的汇总操作隐藏了这些路由背后的细节信息。
1.6.5节讨论的场景与此处描述的问题完全相同，这是因为那个案例使用的默认路由就是去往汇总地址的路由。虽然在1.6.5节已经描述了不希望出现不对称流量的原因，但是从本节可以看出，与汇总带来的好处相比，不对称流量可能是一个值得付出的代价。与网络设计中的大量选项相似，大家需要在汇总的正面效果与不对称流量的负面效果之间做出抉择。
B类地址空间耗尽的主要原因是IPv4地址的类别设计存在固有缺陷。一个C类地址可以提供254个主机地址，而一个B类地址却可以提供65 534个主机地址，两者之间的差距过于悬殊。出现CIDR之前，如果某个公司需要500个主机地址，那么一个C类地址将无法满足该需求。此时就可能需要申请一个B类地址，虽然这样做会浪费65000个主机地址。有了CIDR之后，只要申请/23的地址块即可满足公司的需求，这样就能大大节省传统地址分配方式浪费掉的主机地址。
CIDR抛弃了IPv4最初采用的类别概念，虽然现在有时为了方便起见，仍然会偶尔用到类别的概念。例如，将为IPv4多播预留的地址空间称为D类地址空间，将留作实验用途的大块未用地址块称为E类地址。但是A类地址、 B类地址和C类地址等术语已经完全过时了。由于CIDR术语以前缀的长度来说明地址块的大小：前缀长度越短，地址块所包含的地址数就越多，因而A类、B类和C类地址块在CIDR术语中被分别表示为/8、/16和/24。最重要的是，CIDR的前缀块之间不存在强制性的界限，完全可以包含/23、/22、/21等地址块，直至/0。采用CIDR技术分配地址块的效率更高，能够更好地满足实际需求，不会出现大量浪费现象。
在1993年提出CIDR的时候，Internet路由表路由条目的增长速度远远超出了20世纪70年代首次部署IPv4时的预期。从图1-30可以看出，Internet路由表的路由条目在1988年7月到1992年底的54个月时间里出现了指数式增长，基本上每年增长一倍。
在目前Internet路由表动辄以几十万条路由进行度量的情况下，8500条路由看起来似乎并不大，很多企业网的路由表都可能拥有几千条路由。但是在20世纪90年代早期，内存的价格远高于现在。
图1-30 Internet路由表在1988年到1992年底之间出现指数级增长
但是，比实际的路由表规模更重要的是处理明细路由会给核心路由器带来不稳定影响。这一点与图1-28所解释的问题以及相关讨论相似：如果希望在Internet路由表中看到更长的前缀信息，那么就需要处理更多的BGP更新，从而跟踪更多相对无关紧要的状态变化情况。
如果网络拓扑结构是层次化结构（无论是层次化的OSPF区域还是层次化的自治系统），那么汇总机制能够极大地降低路由表的规模。图1-31给出了一个典型的OSPF设计方案。分配给该OSPF域（AS1）的前缀是198.133.180.0/22。该OSPF域被划分为一个骨干区域和四个非骨干区域，为每个区域分配的前缀都是该AS前缀的一个连续子网[13]。每个区域的ABR负责将单个汇总地址宣告到骨干区域中。这样一来，每个区域中的路由器都通过数据库中的4条Type 3 LSA（类型3 LSA）以及路由表中的4条路由来表示区域外（但位于本OSPF域之内）的全部地址。
虽然图1-32再次列出了拥有前缀198.133.180.0/22的AS1，但此时的AS1只是多个AS网络环境中的一员。AS2拥有前缀198.133.176.0/22。AS1和AS2都连接在服务提供商AS6上。AS6在其拥有的更大的CIDR地址块198.133.176.0/20中分配前缀，而该服务提供商的地址块又是从其服务提供商（AS8）的CIDR地址块198.133.0.0/16中分配得到的。此外，AS8还连接了另一个AS（AS7），并为AS7分配了一个不同的前缀。AS7为三个自治系统提供服务，这三个自治系统也都从AS7的前缀中分配到不同的前缀。
图1-32中的一个重要事实就是所有自治系统都是从单个CIDR前缀（198.133.0.0/16）获得自己的地址空间。因而AS8仅向Internet宣告该前缀，而不会将图中8个自治系统的前缀都宣告到Internet中，这样就能大幅缩减Internet路由表的规模。实际上，AS8可以从自己的/16地址块中分配6个以上的/20地址块或者是其他更长前缀的组合，而不用向Internet宣告除/16之外的任何前缀。
图1-31 IGP域内的汇总操作能够大幅缩减IGP域内的路由表规模
图1-32 在层次化的AS中进行汇总能够有效缩减Internet路由表的规模
很明显，向更高层级的网络域宣告单个汇总地址比宣告成百上千个地址要好得多。更为重要的是，该方案还能极大地增强Internet的稳定性。如果低层级域中的网络状态出现了变化，那么该变化信息最多只会传播给第一个汇总点，而不会传播给更远的网络。
表1-2列出了各种CIDR地址块的规模（直至/8）、折合成C类网络的地址数量以及每个地址块表示的主机数量。
表1-2 CIDR地址块规模
| CIDR地址块前缀大小 |
折合成C类地址数 |
可能的主机地址数 |
|---|---|---|
| /24 |
1 |
254 |
| /23 |
2 |
510 |
| /22 |
4 |
1022 |
| /21 |
8 |
2046 |
| /20 |
16 |
4094 |
| /19 |
32 |
8190 |
| /18 |
64 |
16 382 |
| /17 |
128 |
32 766 |
| /16 |
256 |
65 534 |
| /15 |
512 |
131 070 |
| /14 |
1024 |
262 142 |
| /13 |
2048 |
524 286 |
| /12 |
4096 |
1048574 |
| /11 |
8192 |
2097150 |
| /10 |
16384 |
4194302 |
| /9 |
32768 |
8388606 |
| /8 |
65536 |
16777214 |
在最高层级网络，IANA（Internet Assigned Numbers Authority，互联网数字分配机构）在ICANN（Internet Corporation of Assigned Names and Numbers，互联网名称与数字地址分配机构）的管理下负责分配IP地址。最初的IANA是唯一的IR（Internet Registry，互联网注册机构），也就是申请注册和分配IP地址、AS号等资源的机构，早期由已故的Jon Postel负责运营。
CIDR出现后不久，在IANA下面创建了多个RIR（Regional Internet Registries，区域性互联网注册机构），“以便按照语言及当地习惯更好地为本地区提供服务”（RFC 1366）。目前规范互联网数字地址的文件是RFC 7020，截至本书出版之时，一共有5家RIR。
IANA根据预测需求以/8的CIDR地址块为单位将IPv4地址分配给RIR，由RIR将这些地址块的部分地址分配给LIR（Local Internet Registries，本地互联网注册机构）。LIR通常是一些比较大的ISP，最后再由这些LIR将地址块分配最终客户[14]。对于某些能够证明需要大量地址块的组织机构（如大型企业、学术机构以及政府机关），也可以直接从RIR申请相应的CIDR地址块。
RIR的地址分配策略是为其LIR分配足够大的IPv4地址池，以满足这些LIR的18个月地址需求。出现下列情形时，RIR就会向IANA申请新的地址块：
出现上述情形之一时，IANA就会给RIR分配一个或多个新的/8地址块，使得RIR的可用地址池能够满足未来18个月的分配需求。
5家RIR在给LIR初始分配地址块时采用的都是慢启动策略。为了尽可能地节约IPv4地址，慢启动策略为初始分配定义了一个最小前缀长度（从而获得最大的地址块空间）。每家RIR规定的慢启动大小存在一些细微差异[15]：
所有的RIR都要求申请方在申请新地址块之前，必须保证其已有地址的使用率达到80%以上。例如，ARIN要求申请方必须通过以下两种方式证明其地址使用率：SWIP（Shared WHOIS Project，共享的WHOIS项目）或RWHOIS（Referral WHOIS Server，推荐的WHOIS服务器）。最常用的方式是SWIP，就是将WHOIS信息添加到SWIP模板中并通过电子邮件发送给ARIN。如果要使用RWHOIS，那么就必须在ARIN能够访问WHOIS信息的前端部署一台RWHOIS服务器。这两种方式都能证明LIR已经有效使用了其现有地址空间，而且正在接近耗尽状态。
注：
虽然公有IPv4地址空间的耗尽使得上述讨论看起来似乎毫无意义，截至本书写作之时，AfriNIC是唯一一家没有宣告其IPv4地址空间已经耗尽的RIR。不过IPv6地址块也采取了相似的地址分配策略。由于IPv6地址空间非常巨大，因而IPv6地址的分配策略看起来更慷慨一些。
与此相应，LIR将地址块分配给用户时也鼓励他们使用相同的证明文档。此外，LIR还鼓励其用户尽可能地采用动态地址分配方式（DHCP），以节约有限的IPv4地址资源。
虽然所有的RIR在申请方提供了足够证明文件之后，都会打破他们的慢启动大小规则，但最终分配的前缀长度永远不可能小于/19。当然，有时也会分配更长前缀的地址块，相关内容将在下一节进行讨论。
理解了CIDR以及CIDR地址块的分配方式之后，就可以分析前面曾经提到过的多归属到多个服务提供商时存在的问题了（参见1.6.6节）。
图1-33中的某个AS多归属到两个ISP。其中，ISP1是AS1的LIR（采用上一节描述的地址分配策略）。ISP1从自己的/20 CIDR地址块198.133.176.0/20中给该AS分配了一个前缀（198.133.180.0/22）。两个ISP都将自己的前缀上行宣告给Internet，AS1的前缀是ISP1宣告的聚合地址中的一部分。
图1-33 AS1从ISP1处获得自己的地址前缀
如果这两个ISP之外的其他设备希望向AS1中的目的端发送数据包，那么问题就出现了。Internet路由器将数据包的目的地址匹配为ISP1宣告的聚合地址198.133.176.0/20，因而通过ISP1路由这些数据包（即便从源端到目的端的更佳路径是经由ISP2）。去往AS1中任意目的端的所有数据包（源自这两个ISP之外的源端）都将经由ISP1进行路由。从ISP2进入AS1的唯一入站流量就是源自ISP2或者连接在ISP2上的客户的流量（假设AS2中存在一条去往198.133.180.0/22的路由）。
为了让来自Internet的数据包使用ISP2，就必须让ISP2宣告AS1的前缀（见图1-34）。但这样做又会出现新的问题：从Internet去往AS1的数据包将匹配由ISP2宣告的明细前缀198.133.180.0/22，使得所有去往AS1的流量都将经由ISP2。
图1-34 ISP2宣告了AS1的前缀信息之后，从Internet去往AS1的流量都将经由ISP2
解决这个问题的办法就是让ISP1在自己的CIDR地址块上“打孔”（通常称为地址泄露或去聚合），在宣告汇总前缀的同时还宣告明细前缀198.133.180.0/22（与ISP2的做法相似）（见图1-35）。这样一来，源自Internet的流量就可以通过两条路由进入AS1，数据包也将经由最佳路径进行路由（具体取决于源端的位置）。
图1-35 为了保证去往AS1的数据包能够选择ISP1，ISP1必须在自己的CIDR地址块上“打孔”，
在宣告汇总前缀的同时还宣告明细前缀198.133.180.0/22
图1-35描述的多归属实践方式不但违背了CIDR的初衷，也就是缩减路由表的规模并将网络的不稳定性隐藏到聚合点之后，而且还给提供商以及AS1的用户带来了一些难处，具体情况将在后面进行讨论。
第一个问题就是可携带性。假设为用户分配地址前缀的ISP无法满足该用户的期望或未能完全履行合约协议，或者该用户收到了其他ISP提供的更为优厚的服务提议，那么更换ISP也就意味着必须重新编址。ISP通常不允许用户在迁移到新提供商之后保留其分配给用户的地址块。不但ISP不愿意放弃其地址空间的一部分，而且RIR也强烈建议用户在更换ISP时应该交回已分配的地址空间。
对于终端用户来说，重新编址会带来不同程度的困难。对于那些在自身路由域中使用私有地址空间、在网络边缘使用NAT（Network Address Translation，网络地址转换，详见第10章）的用户来说，重新编址过程应该是最简单的。此时只更改“面向公网”的地址即可，对内部用户的影响最小。另一个极端的终端用户场景就是为每个内部网络设备都静态分配了公网地址，此时这些用户不得不登录网络中的每台设备进行重新编址。
如果终端用户在整个网络域都使用了CIDR地址块，那么通过DHCP可以在一定程度上减轻重新编址所带来的痛苦。此时除了更改DHCP的地址范围并重启用户机器之外，只需对那些静态分配了IP地址的网络设备（如服务器和路由器）进行重新编址即可。
重新编址面临的最大挑战就是变更安全配置。由于防火墙和路由器的访问列表都使用IP地址作为识别数据包的主要方式，因而重新配置这些安全设备将极为耗时且风险较大。
如果变更上游服务提供商的是ISP（而不是终端用户），那么重新编址的问题将变得更加复杂。因为此时不但要对自己的网络进行重新编址，而且还要对所有被该ISP分配了CIDR地址块的用户也都进行重新编址。
虽然图1-33到图1-35显示的ISP1只有单条链路连接Internet，但是在大多数情况下，每个ISP通常都有多条链路连接更高层级的提供商及IXP。提供商必须在这些连接上重新配置其路由器，除了宣告CIDR地址块之外，还要宣告明细路由。由于用户必须密切协调ISP1与ISP2，以确保正确宣告其/22地址块。由于ISP1和ISP2是竞争对手，很难密切配合，因而相应的管理工作也非常复杂。
最后，对于终端用户来说，重新配置路由器的访问列表就是一件极具挑战的任务。对于拥有大量客户以及上游对等互联点的服务提供商来说，面临的困难更是难以估量（因为每个客户以及每个上游对等互联点都配置了复杂的访问列表）。
对于图1-35中的多归属用户来说，解决方案之一就是获得PI（Provider-Independent，与提供商独立的）地址空间。也就是说，用户可以直接向RIR申请一个不属于ISP1或ISP2的CIDR地址块的独立地址块。这样一来，ISP1和ISP2都能在不干扰自身地址空间的情况下宣告该用户的地址块。虽然RIR鼓励用户首先从服务提供商申请地址空间，然后再从提供商的提供商申请地址空间。从RIR申请PI地址空间属于最后手段，但即便这样，用户也面临了很多困难。
首先，如果用户希望采用多归属方式，那么用户的当前地址空间很可能是从最初的ISP申请得到的。那么更换成PI地址空间也就意味着需要进行重新编址，从而面临着前面讨论过的所有难题。
其次，注册管理机构是根据已证明的需求而不是长期预测需求来分配地址空间。该分配策略意味着用户可能只能获得满足当前以及未来3个月预测需求的地址空间，此后必须证明已经有效地使用了原先分配的地址空间才能再次申请新的地址空间。底线就是CIDR的分配规则为小型用户以及ISP带来了困难。
虽然很难申请PI地址空间，但路由的可靠性至少比几年前得到了加强。部分骨干网提供商为了有效加强聚合策略，从而控制Internet路由表的规模及稳定性，并设置相应的策略，以丢弃所有前缀大于/19的路由更新，将前缀长度小于或等于/19的前缀称为“全局可路由前缀”。因此，如果用户宣告了长度大于/19（如/23）的PI前缀或者因去聚合CIDR地址块而宣告了这类前缀，那么就无法保证这类路由宣告能够到达所有Internet，也就无法保证能够从Internet的所有位置到达该用户网络。由于可能会面临用户的投诉窘境，因而提供商已经不再使用该路由策略。
通过控制前缀宣告策略来引导入站流量穿越多条连接的做法也能很好地实现CIDR的去聚合操作。从图1-36可以看出，虽然AS1拥有一个/22的CIDR地址块，但是却将该地址块宣告为4个独立的/24前缀。图中没有显示这4条前缀宣告从AS1到Internet所用的详细路径信息，因为这些路径是随时可变的。这4条前缀宣告既可能穿越两台相同路由器之间的4条链路，也可能穿越4对不同路由器之间的4条链路去往同一个对等互联AS，也可能穿越4条链路去往多个不同的AS。问题的关键就在于AS1将单个/22前缀宣告成了4个/24前缀，从而达到控制入站流量的目的。目的地址为198.133.180.0/22的数据包将匹配这4个更长前缀中的某个前缀，并经由与学到的/24前缀相匹配的路径路由到AS1中。
图1-36 AS1通过去聚合CIDR地址块并在多条独立的路由更新中
宣告更长前缀来达到入站流量的目的
这类流量工程机制通常可以用于多种场合：
假设AS1拥有全球性的网络基础设施，在东京、新加坡、圣何塞以及法兰克福都建立了Internet对等互联。各个地区的网络都通过海缆或洲际光缆进行互连。由于这类带宽非常昂贵，因而网络维护人员希望将这类带宽主要用作AS内部通信，源自外部的数据包都应该尽可能地从最靠近内部目的端的位置进入本AS。
图1-37给出了可能的实现方式。可以看出该AS被划分为4个区域（根据最近的Internet对等互联点），每个区域使用的地址空间都是从/22 CIDR地址块划分出来的/24地址块，并且由每个区域的Internet接入路由器向外宣告这些/24地址。
假设某数据包源自东京的外部网络且目的地址为198.133.183.121（该地址属于AS1慕尼黑机构的某台设备）。此时该数据包并不是通过东京IXP进入AS1，然后再通过AS1昂贵的内部链路到达慕尼黑，而是由Internet路由器将该目的地址匹配为前缀198.133.183.0/24（该前缀由AS1的法兰克福对等互联点宣告），使得该数据包经由AS1的外部网络被路由到法兰克福IXP，然后再进入AS1（该进入点距离慕尼黑的目的端相对较近）。
虽然这种做法能够有效节约AS1的内部带宽，但是却比较自私。这是因为经由Internet到达AS1指定的最便利的入口点的外部网络来转发该数据包的链路，在每比特成本上可能与AS1试图让流量绕开的内部链路相当，而这部分成本是由他人承担的。
这种做法的另一个自私之处在于不是在每个对等互联点宣告单一的/22前缀，而是对该地址块做了去聚合操作并宣告了4个/22的子前缀。但是从图1-37可以看出，为了保险起见，还必须在每个对等互联点宣告该/22 CIDR地址块。如果连接新加坡路由器的外部链路出现故障，无法发送携带198.133.182.0/24的路由更新，那么目的地址属于该前缀的数据包仍然可以匹配较短前缀198.133.180.0/22，从而能够通过其余的三个对等互联点之一路由到AS1中。因此可以看出，AS1向Internet路由表添加的不是一条前缀，而是5条前缀，这么做对于解决Internet路由表爆炸以及Internet的不稳定性毫无贡献。
图1-37 源自AS1外部的数据包都将匹配明细前缀并通过Internet路由到最靠近目的端的
对等互联点进入AS1，而不是在最靠近源端的对等互联点进入AS1
如前所述，发明CIDR（以及NAT和动态编址技术）的目的是延缓IPv4可用地址的耗尽速度并缩减Internet路由表的增长速度，从而为IPv6的开发争取尽可能多的时间。图1-38给出了IANA自启用CIDR（以及启用相应的RIR）以来在1993年到2011年之间分配的IPv4 /8地址块的数量。可以看出，CIDR在20世纪90年代非常有效地延缓了IPv4地址的耗尽速度。
图1-38 IANA每年分配的IPv4/8地址块从2000年开始速度加快[16]
前面曾经说过，部署了CIDR之后，如果用户需要申请新的IPv4地址，那么就必须提供足够的证据来证明已经有效使用了已分配的IPv4地址。从图1-38可以看出，这些规则在1994年至1999年对于延缓IPv4地址的分配速度非常有效，因为在部署CIDR之前已经拥有大量地址块的用户需要首先用完自己的已有地址。但是到了2000年之后，地址块的分配速度再次加快，而且在2000年代的第一个10年内一直保持快速增长的态势，其原因如下：
注：
图1-38中的数据截至2011年，这些年又有什么新变化吗？简而言之，没有什么变化。因为IANA在2011年已经拿出了其地址库中的最后一个可分配的/8地址块，已经没有任何可分配地址了。截至本书出版之时，除AfriNIC之外的所有RIR都已经宣称无可分配IPv4地址或者只剩下最后一个/8地址块。虽然很多LIR仍然拥有一些可分配的IPv4地址，但IPv4地址空间已经不可避免地被耗尽一空了。
CIDR的另一个目标（延缓Internet路由表的增长速度）在20世纪90年代也得到了有效实现。图1-39给出了BGP路由表在1989年到2015年之间的路由数量变化情况[17]。从图中的变化曲线可以看出，路由条数在1989年到1994年初呈现指数增长的趋势。请注意，虽然路由条数在1994年到1999也呈现稳步增长的趋势，但增长曲线并不再是指数增长，而是线性增长：路由条数每年的增长量都基本保持合理的10000条左右。到了1999年至2001年中，该曲线重新回到了指数增长的趋势。此后的增长速度并不是加速了，而是保持在指数增长阶段。
图1-39 从1989年至2015年有效的IPv4 BGP路由条目数可以看出Internet路由表的增长情况[18]
从图1-39可以看出，CIDR从部署之初到1999年期间为延缓Internet路由表爆炸做出了有效贡献，但此后效果一般。如前所述，问题的根源就在于多归属以及流量工程措施导致的去聚合以及长前缀泄露。长前缀对路由表规模的具体影响程度详见表1-3。在表中的528975条有效BGP路由中，只有18.73%属于/20或更短的前缀，53.27%都是/24前缀。因此，如果消除了/24前缀，那么Internet路由表的规模几乎可以削减一半。
表1-3 BGP路由表条数（按前缀长度统计）[19]
| 前缀长度 |
条数 |
占全部条数的百分比 |
|---|---|---|
| /8 |
16 |
0.00 |
| /9 |
12 |
0.00 |
| /10 |
31 |
0.01 |
| /11 |
90 |
0.02 |
| /12 |
262 |
0.05 |
| /13 |
502 |
0.09 |
| /14 |
1024 |
0.19 |
| /15 |
1746 |
0.33 |
| /16 |
13107 |
2.48 |
| /17 |
7424 |
1.40 |
| /18 |
12228 |
2.31 |
| /19 |
25714 |
4.86 |
| /20 |
36949 |
6.99 |
| /21 |
38415 |
7.26 |
| /22 |
56872 |
10.75 |
| /23 |
49556 |
9.37 |
| /24 |
281770 |
53.27 |
| /25 |
1181 |
0.22 |
| /26 |
1127 |
0.21 |
| /27 |
761 |
0.14 |
| /28 |
61 |
0.01 |
| /29 |
51 |
0.01 |
| /30 |
62 |
0.01 |
| /31 |
1 |
0.00 |
| /32 |
13 |
0.00 |
注：
虽然人们通常都将多归属和流量工程视为去聚合的主要原因（见表1-3），但监控Internet的行为后发现，Internet路由表中大多数去聚合前缀的起因并不是有意行为，而是无意的粗心行为：运维人员在能仅宣告聚合路由的情况下仍然宣告了明细路由。
CIDR报告[20]以天为基础给出了聚合操作对于Internet路由表的影响情况，其中非常有用的信息就是定期更新的宣告了去聚合前缀的前30个自治系统以及在这30个自治系统进行聚合的情况下Internet路由表能够改善的程度。截至本节写作之时，列表中的前30个自治系统一共宣告了15046条前缀，同时从Internet BGP表中清除了41798条路由：改善程度达到了73.5%。
CIDR自1993年到2000年左右一直都在按照既定目标发挥作用，虽然此后的实际成效有限，但仍然发挥了重要的正面作用：如果没有CIDR的有效作用，那么2000年之后的第一个十年间，IPv4地址的分配速度以及Internet路由表的增长速度都将更为严峻。
需要注意的是，CIDR（以及NAT和动态IPv4地址分配机制）的任务是为IPv6的发展和部署争取尽可能多的时间，那么为什么CIDR的任务已经完成了，但IPv6却未能在20世纪90年代后期得到规模部署应用呢？
对于上一节末尾提到的IPv6为何在20世纪90年代中期到末期一直未能得到规模部署的问题来说，最简单的答案就是CIDR以及其他权宜之计极为成功，以至于关注IPv4地址持续供给的呼声几乎销声匿迹。由于将已然是庞然大物的IPv4基础设施（包括小至家庭网络、大至顶级运营商网络的所有基础设施）迁移到IPv6是一件非常困难且带有破坏性的任务，因而在CIDR及NAT能够延长IPv4生命期的情况下，几乎没有人愿意开展这方面的工作。
这就出现了“鸡和蛋的问题”：一方面，设备商和应用开发者不愿意将工程资源投入到IPv6的开发当中，原因是客户没有要求他们这么做；另一方面，网络运营商没有规模部署IPv6，原因是几乎没有可用的IPv6网络设备，支持的应用也极少。影响IPv6规模部署的另一个主要因素是没有成熟的商业场景（无法通过部署IPv6来盈利，因而投入没有回报），而且也缺乏“杀手级应用”（IPv6对于消费者来说并没有比IPv4更有吸引力）。
最终，IPv6的驱动力仍来自最初的目标：足够的IP地址。随着CIDR的效果越来越差以及IPv4地址分配速度的加快（见图1-38），网络运营商考虑的不再是商业场景或杀手级应用，而是持续扩展其IP网络及服务的能力。因而在采购标准方面将IPv6作为一个非常关键的要素，这使得设备商以及应用开发者开始逐步投入更多的工程资源。
截至本书写作之时，5家RIR中的4家已经用完了IPv4地址，用户开始大范围地制定自己的IPv6迁移计划。相信读者在阅读本书的时候，IPv6已经进入替代IPv4的早期部署阶段。
虽然IPv6解决了可预见未来的IP地址可用性问题，但是并没有解决路由表爆炸问题。实际上，IPv6可能会使路由表爆炸问题显得更为严峻。IPv4地址的可用性限制以及NAT的使用需求从一定程度上限制了路由表的规模，而IPv6却会大幅拓展该限制。由于Internet路由表中的IPv4路由不大可能消失（至少在IPv6早期部署阶段），因而在IPv6规模部署的早期阶段，至少会使Internet路由表的规模扩张一倍。考虑到IPv6的关键驱动力是丰富的全局可路由地址，大量终端设备（从家用设备到军用及应急服务设备、工业及医疗传感器以及大量移动IP设备）都会配置大量IP地址，因而Internet路由表可能会激增数百万条路由。
随着Internet路由表的持续增长，核心路由平台的性能将持续下降，成本则将持续上升。虽然核心路由平台供应商（如Cisco）在研发更强大的路由器以满足这些挑战方面做了大量工作，但硅基路由器的性能极限已经开始逐步显现。
少数人认为迁移到IPv6是一件很糟糕的事情，因为他们认为这会严重加剧现有基于IPv4的Internet存在的扩展性问题。实际上这是一种误导性观点，原因如下：
考虑到路由表爆炸问题已经开始日益严重，除了要开发有效消除该问题的长期解决方案之外，还必须在开发长期解决方案的同时，利用能够快速推广的短期解决方案缓解路由表爆炸的严重影响。截至本章写作之时，这些解决方案的研究工作才刚刚开始。
虽然有关长期解决方案的研究工作刚刚开展，但必须包含基于新技术（如光交换）的路由器硬件和一种或多种替代BGP的协议。未来路由技术的可能发展趋势就是控制平面（智能）与转发平面（性能）相分离，利用MPLS（Multi-Protocol Label Switching，多协议标签交换技术）等技术将智能推送到网络边缘，并在网络中部署SDN（Software Defined Networking，软件定义网络），从而打破传统的在控制组件与转发组件之间的一对一通信方式。
虽然短期解决方案仍处于讨论阶段，但等到读者阅读本书时可能已经出现。一种可能的解决方案就是管理手段：从多归属及流量工程方面得到好处的用户必须为向Internet路由表泄露长前缀付出更多的代价。如果向Internet路由表泄露长路由需要支付更高的价格，那么对于聚合前缀的用户来说也是一种正向刺激作用。但是对这种做法的可操作性目前仍处于争论之中。
目前正在讨论的另一种短期解决方案就是将IP地址的定位符（locator）功能与标识符（identifier）功能分开：
这两种功能在IP发明之初一直都是重叠的。例如，通过DNS查询设备的名称时，DNS返回的是不会发生变化的IP地址，此时IP地址就是标识符。但是，如果设备移动到一个新子网中，那么DHCP（或IPv6无状态地址自动配置）就会为设备分配一个针对该子网的地址，此时的IP地址就是一个定位符。由于移动IP要求设备必须具有家乡IP地址（标识符）和转交IP地址（定位符），因而这个问题更为复杂。
将定位符功能与标识符功能分离之后，定位符就能更加灵活，也更具可聚合性，使得Internet路由表更加稳定。目前主要的定位符/标识符分离方案如下：
虽然另一种短期解决方案能够宣告更长的前缀以满足多归属或流量工程的需要，但需要对宣告长前缀的路由在被BGP拒绝之前所能穿越的AS数量进行限制。这种AS_PATHLIMIT BGP路由属性是一种折中方案，既允许长前缀路由表项存在于靠近源端AS的位置，又限制这些长前缀的传播距离，以免影响路由选择。但是，考虑到绝大多数Internet路由最多只有5到6个AS跳，因而这种解决方案的效果仍待讨论。
如果读者在阅读本书时，希望了解这些解决方案的最新研究进展，可以参考IETF（Internet Research Task Force，互联网研究工作组）的RPG（Routing Research Group，路由研究组）的网页[21]。
本章从Internet的古老历史（EGP）讲起，讨论了Internet未来发展的一些最新思考及其路由方式，希望读者能够理解BGP以及域间路由背后的概念。第2章将详细讨论BGP协议本身以及相应的配置及故障检测与排除内容。
1．什么是自治系统？
2．IGP与EGP的区别是什么？
3．内部对等体与外部对等体的区别是什么？
4．BGP使用的传输协议以及端口号是什么？
5．BGP AS_PATH路由属性的两个主要作用是什么？
6．BGP利用AS_PATH检测路由环路的方式是什么？
7．末梢AS与转接AS的区别是什么？
8．什么是BGP的路径属性？
9．什么是递归路由查找？
10． BGP在自治系统间宣告路由时，何时向AS_PATH列表添加AS号？何时不向AS_PATH列表添加AS号？为什么？
11．采用全网状BGP结构的目的是什么？为什么这种方式是最佳实践？
12．IBGP避免路由环路的方式是什么？
13．什么是多归属AS？
14．请列举末梢AS采用多归属方式的原因。
15．什么是CIDR？创建CIDR的动因是什么？
16．什么是IP地址前缀？
17．地址汇总对提高网络的稳定性有何作用？
18．实施地址汇总时的可能折中因素是什么？
19．CIDR记法/17是什么意思？
20．什么是互联网注册机构？
21．多归属和流量工程是如何降低CIDR有效性的？
[1] 从1982年这个日期可以看出，RIP已经不是一种新协议，没有任何理由再将RIP作为网络中的主要IGP。就像某位专家在北美网络运营商集团大会上说的那样“目前的RIP表示Rest In Peace（安息吧）”。
[2] 虽然本书的“邻居”与“对等体”可以互换，但两者之间仍存在一些细微差别：邻居指的是两台路由器，且这两台路由器之间直接运行了一条路由协议会话。而对等体指的则是两个邻居，且这两个邻居通过路由协议会话共享可达性信息。
[3] 本章将在1.7节解释有类别路由与无类别路由。
[4] 这只是一种简化的BGP路径选择进程，实际的路径选择进程需要考虑的因素很多，不仅仅是AS_PATH。有关BGP路径选择进程的完整信息将在第2章进行讨论。
[5] 读者可以通过一些公开可访问的路由器来观察Internet路由表、BGP表等信息。本章的路由信息取自俄勒冈大学路由视图项目（www.routeviews.org）的一台公开可访问路由器，并对这些路由信息做了一定的编辑。
[6] IOS有一个与该问题相关的功能，称为IGP同步机制。第3章将详细讨论该机制并提供相应的配置示例。
[7] Tier（层级）是根据对等互联的关系定义的。Tier 1服务提供商之间都是按照免费对等互联方式进行对等互联的；Tier 2服务提供商与部分Tier 1服务提供商（有时是全部Tier 1服务提供商）进行对等互联，但是在费用方式上一般是付费对等互联与免费对等互联相结合；Tier 3服务提供商需要支付其全部上行对等互联费用。不过实际的层级定义并不完全固定不变，Tier 1服务提供商可能在13家到46家左右（取决于所查询的提供商列表）。
[8] 术语IXP已经基本替代了NSFnet时代的术语NAP（Network Access Point，网络接入点），大家可以通过www.datacentermap. com/ixps.html查到世界上最完整的IXP列表信息。
[9] 通常将因为单一中断而破坏了所有冗余链路的问题称为命运共担（fate sharing）。
[10] 本书第一卷的第2章曾经介绍过IPv6，本卷将在全书讨论这种新版本的IP协议。假设读者已经具备了IPv6的相关基础知识，否则建议读者阅读本书第一卷中介绍过的IPv6基础知识，也可以查阅与IPv6协议相关的概述性资料。
[11] RIPv1可能是一个例外，某些小型网络中可能仍在使用RIPv1，有类别路由对于这类网络来说不是问题。
[12] IPv6不存在地址类别的概念，因而相关讨论与IPv6无关。
[13] 本设计方案还说明了使用有效地址汇总机制时的一个有用实践：每个区域的ID都与该区域使用的地址块相对应。
[14] 有时RIR与LIR之间还存在NIR（National Internet Registries，国家互联网注册机构），存在这类NIR例外情况的主要是APNIC所属的亚洲地区。
[15] 虽然这些数字都很精确，但这些并不是RIR分配前缀的全部要求，如果需要了解详细信息，请访问ICANN及NRO（Numbers Resource Organization，号码资源组织）的网站。
[16] 有关IANA分配的IPv4地址块的最新完整信息，请参见www.iana.org/assignments/ipv4-address-space。
[17] 有关该图形的最新信息以及其他AS的相应图形，可参见http://bgp.potaroo.net/index-bgp.html。虽然BGP表项的数量因AS不同而不同，但总体趋势均一致。
[18] 数据来源：http://bgp.potaroo.net/as1221/bgp-active.html，感谢Geoff Huston的许可。
[19] 表中数值截至2014年11月10日。
[20] www.cidr-report.org是表1-3中的数据来源。
[21] www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup
通过第1章的学习，读者应该理解了域间路由的各种关键问题，接下来将详细讨论BGP。本章将讨论BGP的基本操作，包括BGP的消息类型、消息使用方式以及消息格式。此外，本章还要讨论与路由相关联的各种基本的BGP属性以及利用这些属性选择最佳路由的方式，最后将解释BGP对等会话的配置以及故障检测与排除方式。
如果以下4个问题的答案都是“是”，那么就需要BGP：
第一个问题（是否连接了其他路由域）的答案很明显。虽然BGP是一种域间路由协议，但后面将说到，BGP并不是不同域之间的唯一一种路由协议。
根据定义，IGP的潜在假设就是邻居均处于同一个管理机构的管辖范围，因而这些邻居都是可信任的：信任其没有恶意，信任其配置正确，信任其不会发送错误的路由信息。虽然这些问题在同一个IGP域中也偶尔会发生，但通常极少发生。IGP的设计目的是自由地交换路由信息，关注点是性能以及易配置性，而不是对路由信息进行严格控制。
BGP的设计目的是连接不受自己管理控制的域中的邻居。通常无法信任这些邻居，必须利用路由策略仔细控制与这些邻居（如果BGP的配置正确无误）交换的信息。
如果连接外部域是唯一需求（特别是在只有一条连接的情况下），那么就不一定需要BGP。此时静态路由可能是更佳选择，这样就不用担心所交换的信息是错误信息，因为此时根本就不会交换任何信息。静态路由是控制数据包进出网络的最终手段。
图2-1给出的用户通过单一链路接入ISP。此时该拓扑结构就不需要BGP或其他路由协议。如果该单一链路出现故障，由于不存在其他可选路由，因而无需做出任何路由决策。此时路由协议起不到任何作用。因此，该拓扑结构中的用户在边界路由器上配置了一条静态路由，并将该静态路由重分发到本AS中。
与此类似，ISP也会增加一条指向用户地址空间的静态路由并宣告到自己的AS之中。当然，如果用户的地址空间属于ISP更大的地址空间的一部分，那么由ISP路由器宣告的这条静态路由不会被传播到该ISP的AS之外。“其余网络世界”要想到达该用户，只能通过该ISP所宣告的地址空间，只有在ISP的AS之内才能知道到达该用户的精确路由。
处理AS间流量时需要记住的一条重要规则是：每条物理链路实际上代表的是两条逻辑链路，一条用于入站流量，另一条用于出站流量（见图2-2）。
图2-1 单归属拓扑结构的唯一需求就是静态路由
图2-2 自治系统间的每条物理链路代表两条逻辑链路，分别承载入站数据包和出站数据包
在不同方向上宣告的路由仅影响相应方向上的流量。曾经撰写过很多优秀的关于ISP问题文章的Avi Freedman将路由宣告称为承载数据包到达路由中所表示的地址空间的承诺。图2-3中的用户路由器将默认路由宣告到本地AS中——也就是将数据包分发到所有目的地的承诺。同样，宣告了路由205.110.32.0/20的ISP路由器也承诺将流量转发给该用户的AS。因此，来自用户AS的出站流量取决于默认路由，而去往用户AS的入站流量则取决于ISP路由器宣告的路由。虽然这个概念对于本例来说显而易见，但对于今后分析更复杂的拓扑结构以及构造策略来宣告和接受路由来说都是至关重要的。
图2-1显示的拓扑结构存在一个非常明显的脆弱点，那就是整个连接都存在大量单点故障隐患。如果图中的单一数据链路出现故障，如果路由器或路由器的某个接口出现故障，如果某台路由器的配置出现故障，如果路由器的某个进程出现故障，或者是如果某个过于人性化的路由器管理员犯了错误，那么都会导致该用户的整个Internet连接出现故障。这种拓扑结构所欠缺的就是冗余性。
图2-3给出了一个改良后的拓扑结构，用户到同一个服务提供商拥有了冗余链路。至于入站流量和出站链路如何通过冗余链路则取决于这两条链路的使用方式。例如，多归属到单个服务提供商的典型配置方式是将其中的一条链路设置为主用链路（专用Internet接入链路），另一条链路设置为备用链路。
图2-3 多归属时必须考虑入站和出站宣告以及每条链路上产生的流量情况
如果冗余链路仅用做备份，那么也不需要使用BGP。此时的路由宣告方式与单归属应用场景相同，只是需要将与备用链路相关的路由度量设置的高一些，使得这些备用链路仅在主用链路失效时才起作用。
例2-1给出了拥有主用及备用链路时路由器的可能配置信息。
例2-1 多归属到单个自治系统的主用及备用链路配置
Primary Router:
router ospf 100
network 205.110.32.0 0.0.15.255 area 0
default-information originate metric 10
!
ip route 0.0.0.0 0.0.0.0 205.110.168.108
________________________________________________________________________
Backup Router:
router ospf 100
network 205.110.32.0 0.0.15.255 area 0
default-information originate metric 100
!
ip route 0.0.0.0 0.0.0.0 205.110.168.113 150从例2-1的配置可以看出，备用路由器有一条管理距离被设置为150的默认路由。这样一来，仅当主用路由器的默认路由不可用时，该备用路由器的默认路由才会进入路由表。而且备用默认路由以较高的度量值（大于主用默认路由的度量值）进行宣告，以确保OSPF域中的其他路由器优选主用默认路由。这两条路由的OSPF度量类型均为E2，因而所宣告的度量值在整个OSPF域中保持一致。这种一致性可以确保无论到每台边界路由器的内部开销是多少，每台路由器上的主用默认路由的度量值都低于备用默认路由的度量值。例2-2给出了用户OSPF域内的某台路由器的默认路由信息。
虽然主用/备用设计方式满足了冗余性需求，但无法有效地利用可用带宽。一种更好的设计方式是同时使用这两条路径，在链路或路由器出现故障时，这两条路径可以互为备份。此时这两台路由器的配置情况如例2-3所示。
例2-2 首先显示的是主用外部路由，其次显示的是主用路由失效后使用的备用路由
Phoenix#<strong>show ip route 0.0.0.0</strong>
Routing entry for 0.0.0.0 0.0.0.0, supernet
Known via "ospf 1", distance 110, metric 10, candidate default path
Tag 1, type extern 2, forward metric 64
Redistributing via ospf 1
Last update from 205.110.36.1 on Serial0, 00:01:24 ago
Routing Descriptor Blocks:
* 205.110.36.1, from 205.110.36.1, 00:01:24 ago, via Serial0
Route metric is 10, traffic share count is 1
________________________________________________________________________
Phoenix#<strong>show ip route 0.0.0.0</strong>
Routing entry for 0.0.0.0 0.0.0.0, supernet
Known via "ospf 1", distance 110, metric 100, candidate default path
Tag 1, type extern 2, forward metric 64
Redistributing via ospf 1
Last update from 205.110.38.1 on Serial1, 00:00:15 ago
Routing Descriptor Blocks:
* 205.110.38.1, from 205.110.38.1, 00:00:15 ago, via Serial1
Route metric is 100, traffic share count is 1例2-3 负载共享到同一个AS时，两台路由器的配置可以完全相同
router ospf 100
network 205.110.32.0 0.0.15.255 area 0
default-information originate metric 10 metric-type 1
!
ip route 0.0.0.0 0.0.0.0 205.110.168.108注：
将图2-3中的简单对等关系构造为主用/备用配置与负载共享配置的主要区别就在于带宽。如果一条链路主用，另一条链路备用，那么这两条链路的带宽应该相等。主用链路出现故障后，所有负载都能无阻塞地重路由到备用链路上。在某些配置场合，备用链路的带宽通常要比主用链路低得多，这种情况下的假设条件是，主用链路失效后，备用链路仅为关键应用提供足够带宽，而不是为所有网络功能都提供足够的带宽。
如果采用的是负载共享配置方式，那么这两条链路的每一条链路都应该能够承载正常情况下通过这两条链路承载的全部流量，在其中一条链路出现故障后，另一条链路能够不丢包地承载所有流量。
例中两台路由器的静态路由拥有相同的管理距离，而且这两条默认路由均以相同的度量值（10）进行宣告。例中的默认路由正以OSPF度量类型E1进行宣告。对于该度量类型来说，OSPF域中的每台路由器除了要考虑默认路由的开销之外，还要考虑到达边界路由器的内部开销。因而每台路由器在选取默认路由时都会选择最近的出口点（见图2-4）。
在大多数情况下，从多个出口点将默认路由宣告到AS中并在相同的出口点对离开AS的地址空间进行汇总，可以实现很好的网络性能。此时需要考虑的就是非对称流量模式是否存在问题。如果两个（或多个）出口点的地理间隔足够大，以至于时延变化变得很重要时，就可能需要更好地控制路由，这时就可以需要考虑使用BGP了。
例如，假设图2-3中的两台出口点路由器分别位于洛杉矶和伦敦。用户希望所有去往东半球的出流量都使用伦敦路由器，而所有去往西半球的出流量都使用洛杉矶路由器。需要记住的是，入站路由宣告会影响出站流量。如果提供商通过BGP将路由宣告到用户AS中，那么内部路由器将拥有更详细的外部目的地信息。
图2-4 OSPF边界路由器以度量值10和OSPF度量值类型E1宣告默认路由
与此相似，出站路由宣告会影响入站流量。如果内部路由通过BGP宣告给提供商，那么用户就可以决定在哪个出口点宣告哪条路由，并且在将流量发送到用户AS时可以利用BGP提供的工具（在一定程度上）影响提供商的选择。
在考虑是否使用BGP时，需要仔细权衡所得到的好处与增加路由复杂度所带来的代价。只有对流量控制有益时，才应该优选BGP（相对于静态路由而言）。而且还应该分别考虑出站和入站流量。如果仅需要控制入站流量，那么可以通过BGP将路由宣告给提供商，而提供商仍然仅将默认路由宣告给用户AS。
如果仅需要控制出站流量，那么就可以利用BGP仅接收来自提供商的路由，但一定要仔细考虑该接收来自提供商的哪些路由。“接收全部BGP路由”意味着提供商会将整个Internet路由表都宣告给用户。截至本书写作之时，大约有500000条IPv4路由（见例2-4）。 IPv6 Internet路由表也正在快速增长，因而需要配置强大的路由器CPU来处理这些路由，并配置足够的路由器内存来存储这些路由。从例2-4可以看出，仅仅BGP路由就需要大约155.7MB内存，而BGP需要处理这些路由的内存需求更达到了4.1GB左右（见例2-5）。当然，如果采用简单的默认路由方案，那么只要低端路由器以及适量的内存即可轻松实现。
例2-4 Internet路由表的汇总信息显示一共有540809条BGP路由[1]
route-views>show ip route summary
IP routing table name is default (0x0)
IP routing table maximum-paths is 32
Route Source Networks Subnets Replicates Overhead Memory (bytes)
connected 0 2 0 192 576
static 1 57 0 5568 16704
application 0 0 0 0 0
bgp 6447 174172 366637 0 51917664 155752992
External: 540809 Internal: 0 Local: 0
Internal 7847 42922856
Total 182020 366696 0 51923424 198693128
route-views>例2-5 BGP大约需要4.1GB的内存才能处理例2-4中显示的所有路由
route-views> show processes memory | include BGP
117 0 0 232 41864 644 644 BGP Scheduler
176 0 1505234352 262528 370120 14362638 14362638 BGP I/O
299 0 0 10068312 41864 0 0 BGP Scanner
314 0 0 0 29864 0 0 BGP HA SSO
338 0 27589889144 2170064712 4102896864 3946 3946 BGP Router
350 0 0 0 29864 0 0 XC BGP SIG RIB H
383 0 0 0 41864 0 0 BGP Consistency
415 0 0 0 41864 0 0 BGP Event
445 0 0 0 29864 0 0 BGP VA
450 0 3224 0 33160 1 0 BGP Open
562 0 328104 262528 107440 0 0 BGP Task
574 0 3248 0 33160 1 0 BGP Open
575 0 3120 0 33088 1 0 BGP Open
577 0 3120 0 33040 1 0 BGP Open
578 0 3120 0 33072 1 0 BGP Open
route-views>注：
例2-4的路由表汇总信息以及例2-5的相关进程信息取自route-views.oregon-ix.net的路由服务器。读者阅读本书时，这两个示例中的数据可能会发生变化。大家可以通过Telnet登录该服务器并查看当前的最新数据。这类公开可访问的路由服务器很多，可以参阅www.netdigix.com/servers.html。
运行BGP的另一个考虑因素就是需要通过一个AS号来标识用户的路由域。与IPv4地址相似，AS号的数量也是有限的，并且只能由区域性地址注册管理机构根据需要进行分配。与IPv4地址相似，AS号也有一部分被保留用作私有用途：AS号64512～65535。与私有IPv4地址（RFC 1918）相同，这些AS号也不是全局唯一的号码，不能包含在宣告给公共Internet的所有路由的AS_PATH中。几乎毫无例外，连接到单个服务提供商（无论是单归属还是多归属）的用户都使用该保留范围内的AS号，服务提供商则会将这些私有AS号从宣告的BGP路径上过滤掉。有关私有AS号的配置及过滤方式将在第5章进行详细讨论。
虽然图2-3的拓扑结构已经在图2-2的基础上进行了改进（增加了冗余路由器和冗余数据链路），但仍然存在单点故障问题，此时的单点故障就是ISP。如果ISP与Internet的连接出现了故障，那么用户也将无法连接Internet。此外，如果ISP的网络内部出现重大故障，那么该单归属用户也将受到拖累。
图2-5所示拓扑结构中的用户归属到了多个服务提供商网络上。除了前面描述的多归属好处之外，该用户还能防范单个ISP故障导致的Internet连接丢失问题。对于该拓扑结构来说，与静态路由相比，BGP通常是一种更佳选择。
图2-5中的用户也可以不使用BGP。一种可选方式就是将其中的一个ISP用作主用Internet连接，将另一个ISP作为备用。另一种可选方式就是设置指向这两个服务提供商的默认路由，让路由进程自行选择相应的路由。但是，如果用户在多归属上支付了额外费用并与多个服务提供商签订了服务合同，那么就不应该采用这两种解决方案，此时应该优选BGP。
图2-5 多归属到多个自治系统
同样，此时也需要分开考虑入站流量和出站流量。对于入站流量来说，如果将所有的内部路由都宣告给了两个提供商，那么就能达到最可靠的结果，可以确保通过任一个ISP到达用户AS中的所有目的端，即使两个提供商都在宣告相同的路由，入站流量也会优选其中的一条路径（详见第1章中的多归属部分），BGP提供了相应的路径优选工具。
对于出站流量来说，应仔细考虑从提供商接收的路由。如果接受了两个提供商的全部路由，那么就能为所有的Internet目的端选择最佳路由。但是在某些情况下，某个提供商可能是所有Internet连接的优选提供商，而另一个提供商则只是少数目的端的优选提供商，那么就可以接受优选提供商的全部路由，而仅接受另一个提供商的部分路由。例如，如果希望通过次选提供商去往其用户并作为主用Internet提供商的备份（见图2-6），那么就可以让次选提供商发送其客户路由，并配置一条指向该次选ISP的默认路由，在主用ISP的连接出现故障时再使用次选ISP的连接。
请注意，ISP1发送的全部路由中可能会包含ISP2的客户路由（可能学自Internet，也可能学自直接的对等连接），但由于用户会从ISP2收到相同的客户路由，而用户路由器通常都会优选经由ISP2的较短路径，因此，如果到ISP2的链路出现故障，那么用户将使用经ISP1及其他Internet网络的较长路径去往ISP2的客户。
与此类似，用户通常都会选择经ISP1去往除ISP2的客户之外的所有目的端。但是，如果经ISP1的部分或全部精确路由都丢失了，那么用户将选择经ISP2的默认路由。
如果路由器因CPU和内存的限制而无法接收全部路由[2]，那么也可以接收两个提供商的部分路由。每个提供商都会发送自己的客户路由，而用户则将默认路由指向这两个提供商。此时，用户将以牺牲路由的精确性来换取路由器硬件的节省。
图2-6 ISP1是去往大多数Internet连接的优选提供商，ISP2则仅用于
去往其客户网络并作为备用Internet连接
在接收部分路由的其他应用场合，每个ISP除了发送自己的客户路由之外，还有可能发送上游提供商（通常是国家级或全球骨干运营商，如Level 3 Communications、Sprint、NTT或Deutsche Telekom）的客户路由。以图2-7为例，图中的ISP1连接到Carrier1，ISP2连接到运营商2，由ISP1发送给用户的部分路由中包含了ISP1的所有客户路由以及运营商1的所有客户路由，由ISP2发送给用户的部分路由中包含了ISP2的所有客户路由以及运营商2的所有客户路由，用户的默认路由则同时指向这两个提供商。由于两个骨干服务提供商的网络规模都非常大，因而用户拥有足够的路由，能够对大量目的地做出有效的路由决策。当然，与全部Internet路由表相比，部分路由要少得多。
图2-7 用户从两个ISP接收的部分路由中包括所有ISP的客户路由以及上游提供商的客户路由
上述示例显示的末梢AS均连接了一个或多个ISP，从图2-5到图2-7可以看出，不断增加的复杂度使得用户越来越需要部署BGP以及路由策略。随着多归属以及相关路由策略的复杂度增加（如前一章介绍的转接AS示例所述），对BGP的需求也就愈加迫切。
创建BGP对等关系涉及一个有趣的信任与非信任问题。一方面，由于BGP对等体是另一个AS，因而必须信任对端的网络管理员，以了解他们正在做些什么；另一方面，如果足够聪明，还应该检查每个操作，以防止对端网络管理员的错误操作对本网造成损害。在实施BGP对等连接的时候，偏执狂将是您的忠实朋友。
此外，还必须采取有效措施，以免自己的错误给BGP对等体造成影响。
如前所述，路由宣告实质上是一个将数据包分发到所宣告目的端的承诺。对外宣告的路由会直接影响接收到的数据包，而收到的路由会直接影响所发送的数据包。对一个好的BGP对等方案来说，双方都应该完全了解每个方向上宣告的路由，而且必须分别考虑入站流量和出站流量，每个对等体都要确保仅传送正确路由，同时还要使用路由过滤器或其他路由策略工具（如将在第4章描述的AS_PATH过滤器）以确保仅接收正确路由。
ISP一般都不会容忍用户的BGP配置差错，最糟糕的情况是双方的BGP对等方案都出现了故障。举例来说，假如用户因某种错误配置而将207.46.0.0/16宣告给了ISP，对接收方来说，ISP不但没有过滤这条错误路由，而且还将这条路由宣告给了外部Internet，该特定CIDR地址块属于Microsoft，但用户却对外申明拥有去往该目的地的路由。这样一来，大量的Internet团体可能会认为通过该用户路由域去往Microsoft是最佳路由，导致该用户收到大量来自Internet的非期望数据包，更严重的是，该用户接收了应该去往Microsoft的大量黑洞流量，使得用户既烦恼又无法理解。
这种情况还是比较常见的，就在不久以前，首尔的一家公司错误地宣告了一个/14前缀，但是由于该前缀包含了属于Yahoo的地址，使得Yahoo出现了短时中断。
图2-8给出了另一个BGP路由错误案例，图中的互连网络与图2-6类似，区别在于本例中用户从ISP2学习到的客户路由因疏忽而被宣告给了ISP1。
除非ISP1与ISP2之间存在直接的对等连接，否则ISP1及其客户会将用户的路由域视为去往ISP2及其客户的最佳路径。对于本例来说，由于该用户确实有一条去往ISP2的路由，因而这些流量并没有被黑洞化，只是此时的用户域将成为自ISP1去往ISP2的数据包的转接域，对自身的流量不利。由于从ISP2到ISP1的路由仍然要通过Internet，因而该用户会导致ISP2出现不对称路由。
从本质上来说，本节的核心内容就是BGP被设计用来在自主控制的系统之间进行通信。一个成功的、可靠的BGP对等方案不仅需要深入了解每个方向上宣告的路由，而且还要深入了解每个参与方的路由策略。
本章的后面将讨论BGP的基础内容，解释简单BGP会话的配置方式以及故障检测与排除方式，有了这些基础知识之后，就能够很好地理解第4章讨论的BGP配置以及故障检测与排除策略了。
图2-8 用户将学自ISP2的路由宣告给了ISP1，使得去往ISP2及其
客户的数据包经该用户的路由域进行转接
前面曾经在第1章中介绍过BGP的一些基础知识，主要包括下面这些。
本章将以此为基础讨论BGP的操作方式。
在建立BGP对等连接之前，两个邻居必须执行标准的TCP三向握手进程，并打开到端口179的TCP连接。TCP为一条可靠连接提供了分段、重传、确认以及排序等功能，从而将BGP从这些功能中解放出来。所有的BGP消息都采取单播方式经TCP连接传递给邻居。
BGP使用以下4种基本消息类型：
注：
还有第五种BGP消息：Route Refresh（路由刷新），但是与上面提到的四种消息不同，第五种消息并不属于基本的BGP功能，因而可能不是所有的BGP路由器都支持该消息。有关Route Refresh消息的详细内容将在第4章进行讨论。
本节将解释如何使用这些消息，有关这些消息的消息格式以及每个消息字段的变量情况请参见2.2.5节。
TCP会话建立之后，两个邻居之间需要发送Open消息，每个邻居都用该消息标识自己并指定BGP操作参数。Open消息包括以下信息。
如果路由器接受邻居发送的Open消息中指定的参数，那么就响应一条Keepalive消息。此后IOS将默认每60秒发送一条Keepalive消息，或者是按照已协商的保持时间的1/3为周期发送Keepalive消息。与保持时间相似，可以利用timers bgp更改整个BGP进程的保持激活间隔，或者利用neighbor timers更改指定邻居或对等体组的保持激活间隔。
需要注意的是，虽然BGP将部分可靠性功能挪到了底层的TCP会话上，但使用的仍然是自己的Keepalive消息，而不是TCP的Keepalive消息。
Update消息用于宣告可行路由、撤销路由或两者。Update消息包括以下信息。
请注意，虽然NLRI字段可以包含多个前缀，但每条Update消息仅描述单条BGP路径（这是因为路径属性仅描述单条路径，只是该路径可能会通往多个目的端）。需要再次强调的是，BGP是一种比IGP更高层级的互连网络视图（IGP路由总是指向单个目的IP地址）。
路由器检测到差错之后会发送Notification消息，并且总要关闭BGP连接。2.2.5节详细列出了会导致发送Notification消息的各种差错情况。
使用Notification消息的一个例子就是在邻居之间协商BGP版本号。建立了TCP连接之后，如果BGP-3发话路由器收到了一个指定版本号为4的Open消息，那么就会响应一条声明不支持该版本的Notification消息，然后关闭该会话。
可以利用有限状态机来描述BGP连接的建立和维护阶段，图2-9和表2-1给出了完整的BGP有限状态机以及触发状态迁移的各种输入事件。
图2-9 BGP有限状态机
表2-1 图2-9的输入事件（IE）
| IE |
描述 |
|---|---|
| 1 |
BGP启动（Start） |
| 2 |
BGP终止（Stop） |
| 3 |
BGP传输（Transport）连接打开 |
| 4 |
BGP传输（Transport）连接关闭 |
| 5 |
BGP传输（Transport）连接打开失败 |
| 6 |
BGP传输（Transport）致命性错误 |
| 7 |
ConnectRetry（连接重试）定时器到期 |
| 8 |
Hold（保持）定时器到期 |
| 9 |
Keepalive定时器到期 |
| 10 |
接收Open消息 |
| 11 |
接收Keepalive消息 |
| 12 |
接收Update消息 |
| 13 |
接收Notification消息 |
下面将逐一介绍图2-9中的6种邻居状态。
BGP总是以Idle状态为起始点，该状态拒绝所有入站连接。启动（Start）事件（IE 1）发生后，BGP进程会初始化所有BGP资源、启动ConnectRety（连接重试）定时器、初始化去往邻居的TCP连接、侦听来自邻居的TCP初始化并将状态更改为Connect（连接）状态。启动事件由配置BGP进程或重置现有进程的操作员发起，或者由重置BGP进程的路由器软件发起。
如果发生差错，BGP进程将迁移到Idle状态。此时，路由器可能会自动尝试发起另一个启动事件，但应对路由器的这种行为做一定的限制——这是因为在持续性地差错条件下，经常性地重启会导致波动。因而在第一次迁移到Idle状态之后，路由器会设置ConnectRety定时器，在定时器到期时才会重新再启BGP。IOS的初始ConnectRety时间为120秒，该值不可更改，以后每次ConnectRety时间都是之前的两倍，也就是说，连续等待时间呈指数式递增。
该状态下，BGP进程一直等待TCP连接的完成。如果TCP连接建立成功，BGP进程将会向邻居发送Open消息并进入OpenSent（打开发送）状态。如果TCP连接建立不成功，BGP进程将继续侦听由邻居初始化的连接、重置ConnectRety定时器，并迁移到Active（激活）状态。
如果ConnectRety定时器到期时仍处于Connect状态，则重置定时器，并再次尝试与邻居建立TCP连接，进程也将继续维持在Connect状态，其他输入事件将会让BGP进程迁移到Idle状态。
该状态下，BGP进程会尝试与邻居初始化TCP连接。如果TCP连接建立成功，BGP进程会清除ConnectRetry定时器、完成初始化过程、向其邻居发送Open消息，并迁移到OpenSent（打开发送）状态。IOS默认的保持时间为180秒（3分钟），可以通过timers bgp statement命令设置保持时间。
如果ConnectRetry定时器到期时BGP进程仍处于Active状态，那么进程将返回Connect状态并重置ConnectRetry定时器，而且还要与对等体进行TCP连接的初始化并继续侦听来自对等体的连接。如果邻居试图以非期望的IP地址建立TCP会话，则重置ConnectRetry定时器、拒绝该连接，且继续维持在Active状态，其他输入事件（启动事件除外，因为Active状态会忽略启动事件）将会让BGP进程迁移到Idle状态。
该状态下，已经发送了Open消息，BGP会一直等待直至侦听到来自邻居的Open消息。接收到Open消息后，会检查该消息的每个字段，如果存在差错，则会发送Notification消息并迁移到Idle状态。
如果接收到的Open消息没有差错，则发送Keepalive消息并设置Keepalive定时器，此外还要协商保持时间，以确定一个较小的保持时间值，如果协商后的保持时间为零，则不启动保持定时器和Keepalive定时器。根据对等体的AS号，可以确定对等连接是内部连接还是外部连接，并迁移到OpenConfirm（打开确认）状态。
如果收到断开TCP连接的请求，则本地进程将关闭BGP连接、重置ConnectRetry定时器、开始侦听由邻居发起的新连接，并迁移到Active状态。其他输入事件（启动事件除外，因为该状态会忽略启动事件）则会让BGP进程迁移到Idle状态。
该状态下，BGP进程将等待Keepalive消息或Notification消息，如果收到的是Keepalive消息，则迁移到Established（建立）状态；如果接收到的是Notification消息或断开TCP连接请求，则迁移到Idle状态。
如果保持定时器到期，或检测到差错，或发生了终止事件，则向邻居发送一条Notification消息、关闭BGP连接，并将状态更改为Idle状态。
该状态下，BGP对等连接已完全建立，对等体之间可以相互交换Update、Keepalive和Notification消息。如果接收到的是Update或Keepalive消息，则重新启动保持定时器（如果协商好的保持时间不是零）。如果接收到的是Notification消息，则迁移到Idle状态。其他事件（启动事件除外，因为该状态会忽略启动事件）将会让BGP进程发送一条Notification消息并迁移到空闲状态。
路径属性是所宣告BGP路由的特性，虽然该术语专用于BGP，但大家对这个概念并不陌生：每条路由宣告（无论发起的路由协议是何种路由协议）都有属性。例如，每条路由宣告都有表达目的端的某种信息（地址前缀）、能够与去往相同目的端的其他路由进行对比的某种量值（度量）以及关于目的端的方向性信息（如下一跳地址）。BGP不但拥有大家已经熟知的与其他路由协议相同的各种属性，而且还拥有许多用于创建并沟通路由策略的特有属性。
所有的路径属性都可以归入以下4类：
首先，每种属性要么是周知属性（即要求所有BGP实现都能识别这些属性），要么就是可选属性（即不要求所有BGP实现都支持这些属性）
周知属性包括强制属性（即必须包含在所有的BGP Update消息中）或自选属性（即可以包含在特定Update消息中，也可以不包含在特定Update消息中）。
如果可选属性是传递性的，那么BGP进程就应该接受该属性中包含的Update消息（即使该进程并不支持该属性），而且应该将该属性传递给对等体。如果可选属性是非传递性的，那么无法识别该属性的BGP进程可以忽略该属性中包含的Update消息，而且不将该路径宣告给其他对等体。简单而言，就是属性可以通过或不可以通过路由器进行传递。
表2-2列出了所有的BGP路径属性，本节将详细介绍表中列出的三种周知强制属性（因为每条BGP Update消息都必须包含这些属性），此外本节还将介绍被称为权重的Cisco专有属性，其余属性则在用作不同用途时进行讨论，如用作策略使能器（第4章）、扩展（第5章）或携带多种NLRI类型（第6章）。
注：
如果大家熟悉团体（Community）属性和扩展团体（Extended Community）属性，那么就可能会疑惑表2-2为何会将这些属性均列为扩展特性，而不是策略使能器。请注意，策略使能器能够直接影响BGP决策进程，而团体属性的作用则是可以更轻松地将策略应用到一组路由上，而不是影响BGP决策进程。
表2-2 路径属性
| 属性 |
类别 |
RFC |
应用 |
|---|---|---|---|
| ORIGIN |
周知强制属性 |
4271 |
策略 |
| AS_PATH |
周知强制属性 |
4271 |
策略、环路检测 |
| NEXT_HOP |
周知强制属性 |
4271 |
策略 |
| LOCAL_PREF |
周知自选属性 |
4271 |
策略 |
| ATOMIC_AGGREGATE |
周知自选属性 |
4271 |
地址聚合 |
| AGGREGATOR |
可选传递属性 |
4271 |
地址聚合 |
| COMMUNITY |
可选传递属性 |
1997 |
扩展 |
| EXTENDED COMMUNITY |
可选传递属性 |
4360 |
扩展 |
| MULTI_EXIT_DISC(MED) |
可选非传递属性 |
4271 |
策略 |
| ORIGINATOR_ID |
可选非传递属性 |
4456 |
扩展、环路检测、策略 |
| CLUSTER_LIST |
可选非传递属性 |
4456 |
扩展、环路检测、策略 |
| AS4_PATH |
可选传递属性 |
6793 |
扩展、策略 |
| AS4_AGGREGATOR |
可选传递属性 |
6793 |
扩展、地址聚合 |
| Multiprotocol Reachable |
可选非传递属性 |
4760 |
多协议BGP |
| Multiprotocol Unreachable |
可选非传递属性 |
4760 |
多协议BGP |
ORIGIN是一种周知强制属性，指定了路由更新的来源。如果BGP存在多条去往同一个目的端的路由时，那么就将ORIGIN属性作为确定优选路由的要素之一。ORIGIN属性指定的路由来源有下面这些。
虽然ORIGIN属性仍然是BGP标准的强制属性，但是正如上述三种可能来源的第二种所述，ORIGIN属性的作用是帮助大家从EGP转换到BGP。因此，虽然在某些极端的策略配置中可能会用到该属性，但绝大多数情况下都将ORIGIN属性视为一种过时的属性。
AS_PATH属性是一种周知强制属性，该属性利用一串AS号来描述去往由NLRI指定的目的地的AS间（inter-AS）路径或AS级（AS-level）路由。AS发起路由（在其AS内向外部邻居宣告目的地的NLRI）时，会将自己的AS号添加到AS_PATH中。后续的BGP发话路由器在将路由宣告给外部对等体时，也会将自己的AS号添加到AS_PATH中（如图2-10所示），因而AS_PATH描述了路由所经过的全部自治系统（从刚刚到达的AS开始，到发起该路由的源AS结束）。
图2-10 在AS_PATH列表中追加AS号（加在最前面）
请注意，仅当Update消息发送给其他AS时，BGP路由器才会在AS_PATH中添加自己的AS号。也就是说，仅在EBGP对等体之间宣告路由时，才会在AS_PATH中追加AS号。如果是在IBGP对等体（位于同一AS中的对等体）之间宣告路由，那么就不会追加AS号。
一般来说，AS_PATH列表中存在同一AS号的多个实例是毫无意义的，而且还会破坏AS_PATH属性的作用。但是对于某些特定场合来说，在AS_PATH属性中添加特定AS号的多个实例也是非常有用的。请注意，出站路由宣告将直接影响入站流量。一般来说，在图2-10中，从AS500去往AS 100的路由将穿过AS300，这是因为该路由的AS_PATH较短。但是如果去往AS200的链路是AS100的入站流量的优选路径，那么会怎么样呢？举例来说，如果（400,200,100）路径上的链路可能都是10G链路，而（300,100）路径上的链路只有1G，或者AS200是主用提供商，而AS300只是备用提供商，则出站流量将被发送到AS200，因而也希望入站流量走相同的路径。
AS100可以通过更改其所宣告路由的AS_PATH属性来影响入站流量（见图2-11），通过在发送给AS300的列表中增加其AS号的多个实例，AS100可以让AS500中的路由器认为路径（500,200,100）是最短路径。通常将这种在AS_PATH中增加额外AS号的操作称为AS路径预附加（prepending）。
如前所述，AS_PATH属性包含了一系列有序的AS号，用来描述去往特定目的端的路径。实际上，AS_PATH属性可以分为以下两种类型。
这两种类型是通过AS_PATH属性中的类型代码进行区分的，详细内容将在“BGP消息格式”一节进行讨论。
图2-11 AS100在宣告给AS300的AS_PATH中增加了自身AS号的多个实例，
从而影响AS500的路径选择
注：
AS_SEQUENCE和AS_SET都有一个修改版本：分别是AS_CONFED_SEQUENCE和AS_CONFED_SET，功能上与AS_SEQUENCE及AS_SET相同，区别在于AS_CONFED_SEQUENCE和AS_CONFED_SET适用于BGP联盟（Confederation）场景（详见第5章）。
如前所述，AS_PATH属性的另一个功能就是预防环路，如果BGP发话路由器发现从外部对等体收到的路由的AS_PATH中包含自己的AS号，那么就认为该路由出现了环路，从而丢弃该路由。但是，如果执行了前缀聚合操作，那么就有可能丢失某些AS_PATH细节信息。例如，图2-12中的AS3113聚合了AS225、AS237以及AS810宣告的前缀，由于AS3113发起的是聚合前缀，因而与该前缀相关联的AS_PATH仅包含该AS号，从而增大了潜在的环路风险。
图2-12 AS3113的聚合操作导致被聚合前缀的AS_PATH信息丢失
假设AS810拥有一条可选连接去往其他AS（见图2-13），那么来自AS3113的聚合路由将被宣告给AS6571，然后再次返回到AS810。
由于聚合点之后的AS号不在AS_PATH中，因而AS810检测不到潜在的路由环路。接下来，假设AS810中的某个网络（如206.25.225.0/24）出现了故障，那么该AS中的路由器将匹配来自AS6571的聚合路由，从而出现路由环路。
仔细想一想，其实AS_PATH的环路预防功能并不需要列表中的AS号必须以特定顺序出现，唯一需要的就是接收端路由器能够确定自己的AS号是否位于AS_PATH中，因而出现了AS_SET。
图2-13 聚合点出现的AS_PATH信息丢失问题会严重影响AS_PATH的环路避免功能
BGP发话路由器根据从其他AS学到NLRI创建聚合路由时，可以像AS_SET那样，在AS_PATH中包含所有的AS号。例如，图2-14显示了在图2-12的聚合路由中添加了AS_SET的网络情况。
图中的聚合路由仍然以AS_SEQUENCE为起始，接收端路由器能够根据该路径回溯到聚合点，但聚合路由中包含了AS_SET，因而能够避免路由环路。此外，还可以从本例看出AS_SET为何是一个无序列表，这是因为AS3113的聚合点后面还有其他分支路径去往该聚合路由所在的自治系统，因而无法利用有序列表来描述这些分离的路径。
请注意，AS_SET是一种折中解决办法。前面曾经说过，路由汇总的主要好处之一就是路由稳定性，如果属于聚合路由的某个网络出现了故障，那么不会将该故障宣告到聚合点之外，但是如果在聚合路径的AS_PATH中包含了AS_SET，那么该聚合路由的稳定性将大大降低。例如，如果去往图2-14中的AS225的链路出现了故障，那么AS_SET就会发生变化，相应的变化情况也会宣告到聚合点之外。但是，与聚合路由相关联的成员AS号的可见性相比，更应该关注的是聚合路由背后的大量前缀的可见性。
实际上，人们很少在公众Internet的聚合点使用AS_SET。由于存在前面所讨论的潜在路由不稳定问题，加上AS_SET可能会存在不慎包含私有AS号的风险以及其他各种复杂性，RFC 6472建议除了某些特殊场合之外，尽量不要使用AS_SET。虽然大多数Internet级别的BGP实现（包括Cisco IOS）都支持AS_SET，但RFC 6472建议在未来的BGP升级规范中删除AS_SET。
图2-14 在聚合路由的AS_PATH中包含AS_SET，可以恢复聚合路由失去的环路避免功能
顾名思义，该周知属性描述了去往所宣告目的端的路径上的下一跳路由器的IP地址。但是与通常的IGP不同，BGP NEXT_HOP属性所描述的IP地址并不总是邻居路由器的IP地址，其规则如下：
图2-15解释了第一条规则，图中的宣告路由器和接收路由器位于不同的自治系统中，此时NEXT_HOP是外部对等体的接口地址。到目前为止，该操作行为仍然与其他路由协议的期望结果一致。
图2-15 如果BGP的Update消息是通过EBGP进行宣告的，那么
NEXT_HOP属性就是外部对等体的IP地址
图2-16解释了第二条规则，图中的宣告路由器和接收路由器位于同一AS中，且正在宣告的目的端也位于同一AS中，此时与NLRI相关的NEXT_HOP是发起端路由器的IP地址。
图2-16 如果BGP的Update消息是通过IBGP进行宣告的，且所宣告的目的端
位于同一AS中，那么NEXT_HOP属性就是发起路由器的IP地址
请注意，虽然宣告路由器和接收端路由器并不共享相同的数据链路，但IBGP TCP连接是通过IGP发话（IGP-speaking）路由器进行传递的，接收端路由器必须执行递归路由查找（有关递归查找的相关内容请参阅《TCP/IP路由技术（第一卷）》），以便将数据包发送到所宣告的目的端。例如，假设图2-16中地址为172.16.101.2的路由器需要转发目的地址为172.16.5.30的数据包，那么该路由器就会查找该目的地址并匹配前缀172.16.5.0/24，该路由显示的下一跳是172.16.83.2，由于该IP地址并不属于路由器的直连子网，因而路由器必须接着查找到达172.16.83.2的路由，由于该路由（学自IGP）显示的下一跳是172.16.101.1，因而路由器就可以转发数据包了。本例可以帮助大家很好地理解IBGP对IGP的依存关系。
图2-17解释了第三条规则，图中的路由通过EBGP学习到之后传递给了内部对等体。由于目的地在其他AS中，因而通过IBGP连接传递的该路由的NEXT_HOP就是学到该路由的外部路由器的接口地址。
图2-17 如果BGP的Update消息是通过IBGP进行宣告的，且所宣告的目的端位于不同
的AS中，那么NEXT_HOP属性就是学到该路由的外部对等体的IP地址
图2-17中的IBGP对等体必须执行递归路由查找以将数据包转发到207.135.64.0/19，但这里存在一个潜在问题，下一跳地址所属的子网192.168.5.0并不是AS 509的一部分，除非AS边界路由器将该网络宣告到AS 509中，否则IGP（甚至内部对等体）将无法知道该子网。此外，如果该子网不在路由表中，那么去往207.135.64.0/19的下一跳地址也将不可达，去往该目的端的数据包也将被丢弃。事实上，尽管去往207.135.64.0/19的路由已经安装在内部对等体的BGP表中了，但是由于下一跳地址对于该路由器来说无效，因而并没有安装到路由表中。
解决方案之一就是要保证内部路由器知道连接在这两个自治系统上的外部子网，虽然可以使用静态路由，但更好的方式是在外部接口运行被动模式下的IGP。如果某些场合不希望使用该解决方案，那么就可以考虑第二种替代解决方案（该解决方案也被视为最佳实践），也就是利用被称为next-hop-self的配置选项让AS 509中的AS边界路由器在NEXT_HOP属性中设置自己的IP地址，而不是外部对等体的IP地址，此后内部对等体的下一跳路由器地址就是172.16.83.2（IGP知道该地址）。有关next-hop-self配置选项的相关内容将在第3章进行讨论。
权重[3]（WEIGHT）是Cisco的专有BGP路径属性，仅对单台路由器内的路由有效，无法与其他路由器进行通信。分配给每条路由的WEIGHT取值范围是0～65535，权重越大，表明该路由越优。在所有路由特性中，权重是BGP决策进程选择最佳路径时最重要的判断要素（显式指定路由除外）。在默认情况下，所有从对等体学习到的路由的权重均为0，而所有由本地路由器生成的路由的权重均为32768。
既可以为每条路由单独设置权重，也可以为学自特定邻居的多条路由设置权重。例如，对等体A和B可能会向同一个BGP发话路由器宣告相同路由，BGP发话路由器为从对等体A收到的路由分配较高权重之后，就可以优选经由对等体A的路由。请注意，该优先级仅在本地对单台路由器有效，权重信息既不包含在BGP Update消息中，也不会以任何方式宣告给BGP发话路由器的对等体。因而权重仅影响单台路由器的路由决策，而不会影响其他路由器的路由决策。
如果希望AS中的指定BGP路由器在对待某些前缀方面与该AS中的其他路由器对待相同前缀的方式不一样，那么就可以使用权重，但是这么做也存在一定的风险。由于权重仅影响单台路由器的BGP决策进程，因而必须谨慎使用，使用错误可能会产生不可预料的后果，或者产生前后矛盾的路由结果（如环路）。
BGP的RIB（Routing Information Base，路由信息库）包括以下三个部分。
RIB的这三个组成部分既可以是三个完全不同的数据库，也可以是利用指针来区分不同部分的单个数据库。
BGP决策进程通过对Adj-RIBs-In中的路由应用入站路由策略，并向Loc-RIB输入选定的或修改的路由来进行路由选择。BGP决策进程包括以下三个阶段。
除非指定了其他特殊的路由策略，否则第2阶段总是在所有可行路由中为特定目的端选择最精确路由。请注意，如果路由的NEXT_HOP属性指定的地址不可达，那么就不会选择该路由。对于IBGP来说还存在一种特殊情况：未与IGP“同步”的路由将无法选择（见第3章）。
到目前为止，已经了解了可以为增强单台路由器、内部对等体、邻接自治系统以及自治系统之外的路由策略而赋予BGP路由多种属性。路由器在多条去往相同目的端的等价路由之间做出决策时，需要遵循一系列决策规则，这些决策规则就是BGP决策进程。IOS规定的决策进程如下[4]。
1．优选权重最大的路由。如前所述，这是IOS专有功能。
2．如果权重相同，则优选LOCAL_PREF值最大的路由。
3．如果LOCAL_PREF值相等，那么就优选该路由器本地发起并通过network或aggregate命令或重分发操作注入到BGP的路由，也就是说，优选学自同一台路由器上的IGP或直连路由。请注意，通过network命令或重分发操作注入BGP的路由优于通过aggregate- address命令注入的本地聚合路由。有关注入前缀的这些方法将在第4章进行讨论。
4．如果LOCAL_PREF值相等且没有本地发起的路由，那么就优选AS_PATH最短的路由。
5．如果AS_PATH长度相等，那么就优选ORIGIN代码最小的路径，IGP小于EGP，EGP小于Incomplete（不完全）。
6．如果ORIGIN代码相同，那么就优选MED（MULTI_EXIT_DISC）值最小的路由。仅当所有备选路由的AS号均相同时才比较MED值[5]。
7．如果MED相同，那么就优选EBGP路由，次选联盟EBGP路由，最后选择IBGP路由。
8．如果此时的路由仍相同，那么就优选到达BGP NEXT_HOP路径最短的路由，该路由是到达下一跳地址的路由中IGP度量最小的路由。
9．如果此时的路由仍相同，且这些路由均来自同一个邻接AS，并通过命令maximum- paths启用了BGP多路径功能，那么就在Loc-RIB中安装所有等价路由。
10．如果此时的路由仍相同且都是外部路由，那么就优选最开始接收到的路径，由于可以避免新路由抢占老路由，因而可以降低路由翻动的概率。如果启用了语句bgp best path compare-routerid，那么就会忽略本步骤。
11．如果没有启用多路径功能，那么就优选BGP路由器ID最小的路由。如果使用了路由反射机制（见第5章），那么就优选ORIGINATOR_ID最小的路由。
12．如果此时的路由仍相同且使用了路由反射机制，那么就优选CLUSTER_LIST最短的路由。
13．如果此时的路由仍相同，那么就优选IP地址最小的邻居宣告来的路由。
注：
理解BGP决策进程以及每个决策步骤的次序，对于部署BGP来说至关重要。除了必须因此而记住上述决策进程之外，记住上述进程还有助于通过CCIE考试以及入职面试，我不但经常会在面试时询问这些问题，而且也经常在被面试时问到这些问题（可惜的是，我的回答并不总是正确）。
BGP消息是在TCP报文段中使用TCP端口179进行承载的，最大消息长度为4096个八位组，最小长度为19个八位组，所有BGP消息都有一个相同的头部（见图2-18）。对不同类型的BGP消息来说，数据部分可能位于该头部之后，也可能不位于该头部之后。
图2-18 BGP消息头部
表2-3 BGP类型代码
| 代码 |
类型 |
|---|---|
| 1 |
Open（打开） |
| 2 |
Update（更新） |
| 3 |
Notification（通告） |
| 4 |
Keepalive（保持激活） |
| 5 |
Route Refresh（路由刷新）（参见第4章） |
Open消息的格式如图2-19所示，该消息是TCP连接建立后发出的第一条消息，如果收到的Open消息是可接受的，那么就发送一条Keepalive消息，以确认该Open消息。确认了Open消息之后，BGP连接就处于Established（建立）状态，可以发送Update、Keepalive以及Notification消息。
图2-19 BGP Open消息的格式
Open消息的最小长度（包含BGP消息头部）是29个八位组。
BGP Open消息包含以下字段。
Update消息的格式如图2-20所示，该消息的作用是向对等体宣告一条可行路由或撤销多条不可行路由或两者。
图2-20 BGP Update消息的格式
BGP Update消息包含以下字段。
图2-21 Update消息中的路径属性字段的属性类型部分
表2-4 属性类型及相应的属性值[7]
| 类型代码 | 属性类型 | 属性值代码 | 属性值 |
| 1 | ORIGIN | 0 | IGP |
| 1 | EGP | ||
| 2 | 不完全（Incomplete） | ||
| 2 | AS_PATH | 1 | AS_SET |
| 2 | AS_SEQUENCE | ||
| 3 | AS_CONFED_SET | ||
| 4 | AS_CONFED_SEQUENCE | ||
| 3 | NEXT_HOP | 0 | 下一跳IP地址 |
| 4 | MULTI_EXIT_DISC | 0 | 4个八位组的MED |
| 5 | LOCAL_PREF | 0 | 4个八位组的LOCAL_PREF |
| 6 | ATOMIC_AGGREGATER | 0 | 无 |
| 7 | AGGREGATOR | 0 | AS号及聚合设备的IP地址 |
| 8 | COMMUNITY | 0 | 4个八位组的团体标识符 |
| 9 | ORIGINATOR_ID | 0 | 4个八位组的发起方路由器ID |
| 10 | CLUSTER_LIST | 0 | 可变长度的簇ID列表 |
| 14 | MP_REACH_NLRI | 0 | 可变长度多协议BGP NLRI |
| 15 | MP_UNREACH_NLRI | 0 | 可变长度多协议BGP NLRI |
| 16 | EXTENDED COMMUNITIES | 0 | 16个八位组的扩展团体标识符 |
| 17 | AS4_PATH | 0 | 采用4个八位组AS号的AS路径 |
| 18 | AS4_AGGREGATOR | 0 | 4个八位组的AS号以及聚合设备的IP地址 |
Keepalive消息以保持时间的1/3（但不得小于1秒钟）为周期进行交换，如果协商后的保持时间为0，那么就不发送Keepalive消息。
Keepalive消息仅包含长度为19个八位组的BGP消息头部，不包含其他数据。
Notification消息的格式如图2-22所示，路由器检测到差错条件之后就会发送该消息。该消息发出后，将立即关闭BGP连接。
图2-22 BGP Notification消息的格式
BGP的Notification消息包括以下字段。
表2-5 BGP Notification消息的差错代码和差错子代码
| 差错代码 | 差错 | 差错子代码 | 子代码细节 |
| 1 | 消息头部差错 | 1 | 连接未同步 |
| 2 | 错误的消息长度 | ||
| 3 | 错误的消息类型 | ||
| 2 | Open消息差错 | 1 | 不支持的版本号 |
| 2 | 错误的对等AS | ||
| 3 | 错误的BGP标识符 | ||
| 4 | 不支持的可选参数 | ||
| 5 | 验证失败（已被RFC 4271废除） | ||
| 6 | 不接受的保持时间 | ||
| 3 | Update消息差错 | 1 | 错误的属性列表 |
| 2 | 无法识别的周知属性 | ||
| 3 | 缺失周知属性 | ||
| 4 | 属性标记差错 | ||
| 5 | 属性长度差错 | ||
| 6 | 无效的ORIGIN差错 | ||
| 7 | AS路由环路（已被RFC 4271废除） | ||
| 8 | 无效的NEXT_HOP属性 | ||
| 9 | 可选属性差错 | ||
| 10 | 无效的网络字段 | ||
| 11 | 错误的AS_PATH | ||
| 4 | 保持定时器超时 | 0 | - |
| 5 | 有限状态机差错 | 0 | - |
| 6 | 终止 | 0 | - |
许多刚接触BGP的读者都有些缺乏信心，这是因为BGP实现要远远复杂于IGP实现。除ISP之外的大多数网络管理员在BGP的处理经验上远不及IGP，即便使用了BGP，小型ISP和非ISP用户所作的配置操作也非常基础。由于大多数网络专业人士对BGP协议都缺乏深层次的了解，因而常常将BGP视为一种神秘或令人畏惧的路由协议。
毋庸置疑，BGP的配置非常复杂，但BGP配置的复杂性主要在于策略，BGP对等关系的配置实际上并不十分复杂，即使其复杂度仍然高于大多数IGP配置。本节将由简入难地详细介绍BGP对等关系配置的每一个步骤。
配置路由器之间的BGP会话的步骤如下。
图2-23显示了两台位于不同自治系统中的路由器，例2-6则给出了这些路由器的EBGP配置。
利用debug ip bgp[8]命令可以查看路由器Vail的BGP状态变化情况（见例2-7），从输出结果的前几行可以看出，Vail正试图打开到达路由器Taos（192.168.1.255）的连接，由于此时还未在Taos上启用BGP，因而尝试失败，并且Vail显示目前的Taos处于Active状态。后来由于在Taos上启用了BGP，因而接受了TCP连接，随着Vail发送Open消息以启动BGP会话，Taos的状态也从Active迁移到OpenSent状态。此后这两台路由器开始进行能力协商（本例协商的能力是多协议以及路由刷新能力，分别在第6章和第4章进行讨论），能力协商一致之后，Vail就将Taos的状态从OpenSent更改为OpenConfirm状态，最后进入Established状态。
图2-23 Taos与Vail建立了EBGP会话
例2-6 图2-23中的路由器的EBGP配置
Taos
router bgp 200
neighbor 192.168.1.226 remote-as 100
Vail
router bgp 100
neighbor 192.168.1.225 remote-as 200例2-7 利用debug命令查看BGP会话建立前后路由器Vail对于Taos的BGP状态变化情况
Vail#debug ip bgp
BGP debugging is on for address family: IPv4 Unicast
Vail#
BGP: 192.168.1.225 open active, local address 192.168.1.226
BGP: 192.168.1.225 open failed: Connection refused by remote host, open active d
elayed 34034ms (35000ms max, 28% jitter)
BGP: 192.168.1.225 open active, local address 192.168.1.226
BGP: 192.168.1.225 went from Active to OpenSent
BGP: 192.168.1.225 sending OPEN, version 4, my as: 100, holdtime 180 seconds
BGP: 192.168.1.225 send message type 1, length (incl. header) 45
BGP: 192.168.1.225 rcv message type 1, length (excl. header) 26
BGP: 192.168.1.225 rcv OPEN, version 4, holdtime 180 seconds
BGP: 192.168.1.225 rcv OPEN w/ OPTION parameter len: 16
BGP: 192.168.1.225 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 192.168.1.225 OPEN has CAPABILITY code: 1, length 4
BGP: 192.168.1.225 OPEN has MP_EXT CAP for afi/safi: 1/1
BGP: 192.168.1.225 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
BGP: 192.168.1.225 OPEN has CAPABILITY code: 128, length 0
BGP: 192.168.1.225 OPEN has ROUTE-REFRESH capability(old) for all address-families
BGP: 192.168.1.225 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
BGP: 192.168.1.225 OPEN has CAPABILITY code: 2, length 0
BGP: 192.168.1.225 OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: 192.168.1.225 rcvd OPEN w/ remote AS 200
BGP: 192.168.1.225 went from OpenSent to OpenConfirm
BGP: 192.168.1.225 went from OpenConfirm to Established利用neighbor remote-as命令创建了邻居之后，就会在BGP邻居数据库中为指定邻居创建一个表项，show ip bgp neighbors[9]命令既可以显示整个BGP邻居数据库，也可以显示指定邻居表项。例2-8显示了Vail记录的关于Taos的相关信息，这些信息对于故障检测与排除操作来说非常有用。
例2-8输出结果中的第一行显示了Taos的地址（192.168.1.255）、AS号（200）以及到达该路由器的BGP连接的类型（外部链路），第2行显示了Vail与Taos之间使用的BGP版本号以及Taos的路由器ID，第3行首先显示BGP有限状态机的状态以及当前对等连接建立后的时间，本例中的Vail已经与Taos持续对等了23分25秒钟。
另一个有意思的信息就是底层TCP连接的细节信息，例2-8以高亮方式显示了这部分信息，表明该TCP连接的状态为Established，Vail通过TCP端口13828向外发送BGP消息，Taos侧的目的端口为179。需要注意的是，如果在一条承载了多个BGP会话的链路上抓取数据包，那么源端口号将非常重要。
例2-8 show ip bgp neighbors命令的输出结果包含了到邻居的对等连接的详细信息
Vail#show ip bgp neighbors
BGP neighbor is 192.168.1.225, remote AS 200, external link
BGP version 4, remote router ID 192.168.1.225
BGP state = Established, up for 00:23:25
Last read 00:00:25, last write 00:00:25, hold time is 180, keepalive interval
is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 5 5
Notifications: 0 0
Updates: 0 0
Keepalives: 51 52
Route Refresh: 0 0
Total: 56 57
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP table version 1, neighbor version 1/0
Output queue size: 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0
Connections established 5; dropped 4
Last reset 00:26:11, due to Peer closed the session
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 192.168.1.226, Local port: 13828
Foreign host: 192.168.1.225, Foreign port: 179
Connection tableid (VRF): 0
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0xA9F664):
Timer Starts Wakeups Next
Retrans 26 0 0x0
TimeWait 0 0 0x0
AckHold 25 2 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
Linger 0 0 0x0
ProcessQ 0 0 0x0
iss: 842497347 snduna: 842497887 sndnxt: 842497887 sndwnd: 15845
irs: 2329656545 rcvnxt: 2329657085 rcvwnd: 15845 delrcvwnd: 539
SRTT: 435 ms, RTTO: 1159 ms, RTV: 724 ms, KRTT: 0 ms
minRTT: 212 ms, maxRTT: 992 ms, ACK hold: 200 ms
Status Flags: active open
Option Flags: nagle
IP Precedence value : 6
Datagrams (max data segment is 1460 bytes):
Rcvd: 50 (out of order: 0), with data: 25, total data bytes: 539
Sent: 31 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0)
, with data: 26, total data bytes: 539
Packets received in fast path: 0, fast processed: 0, slow path: 0
fast lock acquisition failures: 0, slow path: 0
Vail#BGP路由器之间的TCP连接既可以是IPv4，也可以是IPv6。需要记住的是，TCP会话的端点地址与运行在该TCP连接上的BGP会话所支持的地址簇没有关系，也与BGP交换的前缀类型无关，无论TCP会话基于IPv4地址还是IPv6地址，BGP都能同时交换IPv4和IPv6前缀。
图2-24中的两台路由器与图2-3相同，区别在于本例中的接口均配置了IPv6地址，例2-9显示了这两台路由器的EBGP配置，可以看出它们的配置信息与前一个案例基本相同，区别在于邻居地址为IPv6地址。
例2-10显示了Vail的show ip bgp neighbors命令输出结果（在例2-9的配置已经完成的情况下），可以看出此时的邻居信息与例2-8几乎完全相同（也以高亮方式显示），区别在于此时的地址为IPv6地址。不过需要注意的是，Vail的BGP路由器ID仍然是192.168.1.225，由于BGP路由器ID是一个32比特数值，因而无法从IPv6地址中推导出来。
图2-24 Taos与Vail之间建立了EBGP会话（此时都是IPv6端点）
例2-9 图2-4中的路由器的EBGP配置
Taos
router bgp 200
neighbor 2001:db8:0:224::1 remote-as 100
Vail
router bgp 100
neighbor 2001:db8:0:224::2 remote-as 200例2-10 本例的邻居数据库与例2-8看起来非常相似，区别在于此时的邻居地址为IPv6地址
Vail#show ip bgp neighbors
BGP neighbor is 2001:DB8:0:224::1, remote AS 200, external link
BGP version 4, remote router ID 192.168.1.225
BGP state = Established, up for 00:00:18
Last read 00:00:18, last write 00:00:18, hold time is 180, keepalive interval
is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 6 6
Notifications: 0 0
Updates: 0 0
Keepalives: 240 280
Route Refresh: 0 0
Total: 246 286
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP table version 1, neighbor version 1/0
Output queue size: 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0
Connections established 6; dropped 5
Last reset 00:00:39, due to Peer closed the session
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 2001:DB8:0:224::2, Local port: 179
Foreign host: 2001:DB8:0:224::1, Foreign port: 59051
Connection tableid (VRF): 0
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x285A1B0):
Timer Starts Wakeups Next
Retrans 3 0 0x0
TimeWait 0 0 0x0
AckHold 2 0 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
Linger 0 0 0x0
ProcessQ 0 0 0x0
iss: 1579724289 snduna: 1579724392 sndnxt: 1579724392 sndwnd: 16282
irs: 4090406841 rcvnxt: 4090406944 rcvwnd: 16282 delrcvwnd: 102
SRTT: 253 ms, RTTO: 2915 ms, RTV: 2662 ms, KRTT: 0 ms
minRTT: 40 ms, maxRTT: 1484 ms, ACK hold: 200 ms
Status Flags: passive open, gen tcbs
Option Flags: nagle
IP Precedence value : 6
Datagrams (max data segment is 1440 bytes):
Rcvd: 6 (out of order: 0), with data: 3, total data bytes: 102
Sent: 3 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0),
with data: 3, total data bytes: 230
Packets received in fast path: 0, fast processed: 0, slow path: 0
fast lock acquisition failures: 0, slow path: 0从本例邻居数据库的高亮部分还可以看出，本会话仅支持IPv4单播前缀宣告，未配置该路由器的BGP会话承载其他地址簇（见第6章），因而本EGBP会话（虽然该会话运行在两个IPv6端点之间）只能承载IPv4前缀（也是默认地址簇）。
例2-8与例2-10中的TCP会话有一个细微区别，虽然该区别与IPv4或IPv6无关，但仍值得说明一下。例2-8中的本地（Vail的）TCP端口是临时性的，而远程（Taos的）TCP端口是179，例2-10则正好相反：Vail的本地TCP端口是179，而位于Taos的远程TCP端口则是临时性的。第一种场景下的TCP连接（BGP的TCP连接始终指向端口179）是由Vail发起的，而第二种场景下的TCP连接则是由Taos发起的，这些都与TCP连接的历史事实完全一致：配置第一个示例时，首先配置的是Vail的BGP，然后再配置Taos的BGP（从例2-7可以看出，Vail正试图在Taos准备好之前连接Taos）。配置第二个示例时，首先配置的是Taos的BGP，然后配置的才是Vail的BGP。留心这些小细节对于排障以及完全理解特定BGP会话来说都非常有用。此外，如果在BGP接口上运行了访问列表，那么观察这类细节信息也非常重要。虽然可以配置ACL以允许TCP端口179，但是由于会话方向的不同，ACL可能会在无意间阻塞临时端口。
图2-25显示了另一个AS（AS400）连接到AS100上（为简化起见，连接Vail和Taos的接口仍然是IPv4），AS100中增加了两台路由器——Aspen和Telluride，并且Telluride通过EBGP连接了Alta（位于AS400中）。
图2-25 AS100增加了两台路由器并通过IBGP进行对等互连，
因而AS200和AS400可以经由AS100进行通信
AS100中的三台路由器与该AS中的其他两台路由器均有一个IBGP对等会话，在1.5节曾经说过，基于以下两条理由必须建立全网状IBGP连接（同一AS中的每台BGP路由器之间都必须建立一条直接的IBGP连接）。
从总体上来说，IBGP对等会话的配置方式与EBGP对等会话完全相同，之所以是IBGP而不是EBGP，原因就在于neighbor remote-as命令引用的AS号与router bgp命令引用的本地AS号完全相同。例2-11给出了Vail、Aspen以及Telluride的配置信息，从这三台路由器配置中的router bgp语句可以看出，它们都位于AS100，而且还可以看出这些配置中的neighbor remote-as语句也都指向AS100，因而可以判断出这些会话都是IBGP会话。
例2-11 图2-25中AS100的路由器配置
Vail
router bgp 100
neighbor 192.168.1.197 remote-as 100
neighbor 192.168.1.222 remote-as 100
neighbor 192.168.1.225 remote-as 200
________________________________________________________________________
Aspen
router bgp 100
neighbor 192.168.1.197 remote-as 100
neighbor 192.168.1.221 remote-as 100
________________________________________________________________________
Telluride
router bgp 100
neighbor 192.168.1.198 remote-as 100
neighbor 192.168.1.205 remote-as 400
neighbor 192.168.1.221 remote-as 100例2-12介绍了另一条日常维护和检测与排除BGP网络故障的常见命令：show ip bgp summary[11]，该命令可以显示路由器上配置的BGP对等会话的摘要信息以及每个对等会话的状态信息。该命令的输出结果首先显示本地路由器的BGP路由器ID、AS号以及BGP表的当前版本（如果策略或其他行为改变了BGP表的内容，那么BGP表的版本也会随之递增），在这些信息之后，将会显示每个已配置邻居的如下信息：
例2-12 虽然其他BGP会话已经建立，但Vail与Telluride之间的IBGP对等会话仍未建立，处于Active状态
! Vail
Vail#show ip bgp summary
BGP router identifier 192.168.1.226, local AS number 100
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.1.197 4 100 0 0 0 0 0 never Active
192.168.1.222 4 100 29 22 1 0 0 00:18:59 0
192.168.1.225 4 200 43 43 1 0 0 00:00:12 0
! Aspen
Aspen#show ip bgp summary
BGP router identifier 192.168.1.222, local AS number 100
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.1.197 4 100 12 20 1 0 0 00:15:43 0
192.168.1.221 4 100 23 30 1 0 0 00:26:14 0
! Telluride
Telluride#show ip bgp summary
BGP router identifier 192.168.1.206, local AS number 100
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.1.198 4 100 21 13 1 0 0 00:10:06 0
192.168.1.205 4 400 4 5 1 0 0 00:01:06 0
192.168.1.221 4 100 0 0 0 0 0 never Active从图2-12显示的三部分内容可以看出，除了Vail（192.168.1.221）与Telluride（192.168.1.197）之间的IBGP会话之外，其余的IBGP会话以及EBGP会话均已建立，Vail和Telluride均将对方显示为Active状态。快速浏览一遍Vail的路由表（见例2-13）即可发现原因：Vail没有去往Telluride的接口192.168.1.197的路由，虽然本例没有显示Telluride的路由器，但Telluride也没有去往Vail的接口192.168.1.221的路由。
例2-13 Vail没有去往192.168.1.197的路由，因而无法与Telluride建立IBGP会话
Vail#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
192.168.1.0/30 is subnetted, 2 subnets
C 192.168.1.224 is directly connected, Serial1/0
C 192.168.1.220 is directly connected, FastEthernet0/0
Vail#这个简单示例解释了部署IBGP时可能遇到的一个非常普遍的问题。与IGP不同，IBGP会话通常会跨越多个路由器跳，因而除非路由器知道如何到达对等体，否则无法与对等体建立IBGP会话。因此，在检测与排除处于Active状态（侦听已配置邻居）的IBGP会话故障时，首先就要查看这两个邻居的路由表，以确定它们是否知道如何到达对方。
虽然在AS100中配置IGP（本例使用的是OSPF）能够解决Vail与Telluride之间的IBGP会话问题，但实际上只要让这两个邻居的路由表中拥有它们所需的可达性信息即可。例2-14表明目前Vail的路由表中已经拥有了去往子网192.168.1.196以及为Telluride配置的邻居地址192.168.1.197的路由。从例2-15可以看出，AS100中的三台路由器都已经通过OSPF交换了内部可达性信息，因而所有的IBGP会话均处于Established状态。
例2-14 配置了IGP（本例为OSPF）之后，Vail就拥有了去往Telluride的路由
Vail#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
192.168.1.0/30 is subnetted, 3 subnets
C 192.168.1.224 is directly connected, Serial1/0
O 192.168.1.196 [110/2] via 192.168.1.222, 00:00:07, FastEthernet0/0
C 192.168.1.220 is directly connected, FastEthernet0/0
Vail#例2-15 Vail与Telluride目前都已经知道如何到达对方，因而两者之间的IBGP会话已处于Established状态
Vail#show ip bgp summary
BGP router identifier 192.168.1.226, local AS number 100
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.1.197 4 100 4 4 1 0 0 00:00:05 0
192.168.1.222 4 100 93 56 1 0 0 00:00:56 0
192.168.1.225 4 200 131 142 1 0 0 00:00:05 0
Aspen#show ip bgp summary
BGP router identifier 192.168.1.222, local AS number 100
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.1.197 4 100 47 81 1 0 0 00:02:53 0
192.168.1.221 4 100 57 95 1 0 0 00:03:31 0
Telluride#show ip bgp summary
BGP router identifier 192.168.1.206, local AS number 100
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.1.198 4 100 82 47 1 0 0 00:02:09 0
192.168.1.205 4 400 84 73 1 0 0 00:01:03 0
192.168.1.221 4 100 5 5 1 0 0 00:01:37 0虽然图2-25中的IBGP配置已经完成，但拓扑结构仍然有问题：如果Telluride与Aspen之间的链路或Aspen与Vail之间的链路出现了故障，那么AS100将无法与AS400进行通信，因而AS100需要一个更具弹性的拓扑结构，从而可靠地转发数据包并交换BGP信息。从图2-26可以看出，在Telluride与Vail之间增加了一条链路之后，就可以增强AS100的冗余性，从而解决了单条内部链路的故障隐患问题。
图2-26 Telluride与Vail之间的链路为AS100提供了冗余性
虽然增加的这条链路为AS100提供了一定程度的冗余性，但同时也对AS100的IBGP配置提出了一个新问题。如果链路出现故障，那么希望原先使用该链路的IBGP会话能够通过替代路径进行重路由，但是由于IBGP会话运行在物理接口之间，因而无法确定一定可以实现。一种可能的解决办法就是配置冗余的IBGP会话，例如，可以在192.168.1.193与192.168.1.194之间以及192.168.1.221与192.168.1.197之间为Vail与Telluride配置IBGP对等会话。但是，随着AS拓扑结构复杂度的不断增加，这种方法（所有路由器都要配置到所有物理接口的冗余IBGP连接）会导致BGP的配置长度以及IBGP会话数量的急剧增加。
更好的解决方案是在环回接口（而不是物理接口）之间配置对等会话（见图2-27），需要注意的是，图中已经删除了所有的物理链路。如果在环回地址之间建立对等会话，那么就可以从IBGP的拓扑结构中删除物理接口的依赖性，AS内的每台路由器之间都只需要单个IBGP会话，而且该会话是通过最佳可用路径进行路由的。如果路径上的某条链路出现了故障，那么IBGP会话就可以通过次优路径进行重路由（在绝大多数情况下，这种重路由操作非常快，不会导致BGP会话的中断）。
在环回接口之间配置IBGP对等会话需要额外的配置语句，不仅要为IBGP会话的远端指定邻居的环回地址（而不是物理地址），而且还必须将本地路由器的环回接口指定为IBGP会话的发起端。
例2-16给出了改进后的Vail配置信息，虽然EBGP配置仍然相同，但此时的Aspen和Telluride的neighbor remote-as语句指向的都是这些路由器的环回接口地址，而不再是前面配置示例中的物理接口地址。Aspen和Telluride的IBGP配置目前指向的也都是环回接口，而不再是物理接口。
但是这么做还不够，在默认情况下，出站TCP会话源自出站物理接口地址。如果图2-27中的每台路由器都试图从物理接口发起自己的IBGP TCP会话并进入环回接口，虽然其对等体也在物理接口发起会话并在本地路由器的环回接口终止会话，但这些试图建立的TCP会话的端口始终无法匹配，相应的会话也就无法建立。
图2-27 利用环回接口作为IBGP端点可以消除IBGP会话对物理接口的依赖性
因而neighbor update-source语句指示路由器在发起TCP会话时必须从指定的本地环回接口去往指定邻居。
例2-16 在环回地址之间建立对等会话时要求neighbor update-source语句指示会话的本地端应该源自本地环回接口（如修改后的Vail配置所示）
router bgp 100
neighbor 192.168.1.225 remote-as 200
neighbor 192.168.100.2 remote-as 100
neighbor 192.168.100.2 update-source Loopback0
neighbor 192.168.100.3 remote-as 100
neighbor 192.168.100.3 update-source Loopback0例2-17给出了图2-27中的AS100的三台路由器的配置结果，目前的IBGP会话均处于Up状态（因为OSPF正在宣告环回地址），而且还可以发现与前述会话之间的区别，在Open消息一节曾经说过，BGP选择路由器ID的方式与OSPF相同：优选环回地址，如果环回地址不可用，那么就选择数值最大的物理接口地址。由于新配置中的环回地址均可用，因而从例2-17可以看出，这三台路由器的BGP路由器ID都是该路由器的环回地址。由于可能会用同一个环回地址以不同的方式来标识路由器（如OSPF路由器ID，甚至是通过域名以Telnet方式登录路由器时的DNS表项），因而使用环回地址作为BGP路由器ID不但能够增强一致性，而且还易于识别BGP ID。
2.3.5节将讨论一种更好的配置方式，用于配置可预测且一致的BGP路由器ID。
例2-17 IBGP会话目前已运行在环回接口（而不是物理接口）之间
Vail#show ip bgp summary
BGP router identifier 192.168.100.1, local AS number 100
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.1.225 4 200 5 5 1 0 0 00:01:09 0
192.168.100.2 4 100 15 14 1 0 0 00:11:26 0
192.168.100.3 4 100 12 13 1 0 0 00:09:00 0
Aspen#show ip bgp summary
BGP router identifier 192.168.100.2, local AS number 100
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.100.1 4 100 14 14 1 0 0 00:11:42 0
192.168.100.3 4 100 11 13 1 0 0 00:08:59 0
Telluride#show ip bgp summary
BGP router identifier 192.168.100.3, local AS number 100
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.1.205 4 400 8 7 1 0 0 00:03:02 0
192.168.100.1 4 100 20 20 1 0 0 00:17:09 0
192.168.100.2 4 100 21 19 1 0 0 00:16:51 0目前只有前一个案例中的IBGP会话运行在环回地址之间，EBGP会话仍然运行在直连物理接口之间，这也是绝大多数EBGP会话的标准实践方式。IOS默认设置通过以下两种措施来确保外部BGP对等体之间是直接相连的：
不过，有时在环回接口之间运行EBGP也非常有用。以图2-28为例，Telluride与Alta之间通过4条等价链路直连，为了降低配置的复杂性，当然不希望为每条链路都配置独立的EBGP会话（共配置4个独立的EBGP会话），而且更重要的是，这么配置会导致BGP在路由器之间宣告4组完全相同的前缀集，从而降低了网络的可扩展性。
与此同时，也不希望仅选择4条链路中的一条链路承载EBGP会话，如果该链路出现故障，那么将会导致EBGP故障（即使路由器之间的其他3条链路仍然正常），因而希望利用这4条并行链路的冗余性以及负载共享能力。对于该场景来说，解决方案[12]就是在路由器的环回接口之间运行EBGP（见图2-29）。
该配置与前面说过的IBGP案例的配置相似：需要将邻居的环回地址指定为邻居地址，利用neighbor update-source语句从本地环回接口发起EBGP会话，并配置相应的机制让会话两端的路由器都能发现远端对等地址。根据定义，IGP无法运行在不同自治系统之间的路由器上，因而本例使用的是静态路由，为每条物理链路都配置一条指向远端环回地址的静态路由，并将链路的远端地址制定为下一跳。例2-18给出了Alta的EBGP配置示例，Telluride的配置与此相似。
图2-28 4条等价链路连接了Telluride和Alta
图2-29 为EBGP端点使用环回接口可以利用多条物理链路的冗余性和负载共享能力
例2-18 Alta的EBGP配置指定其发起并去往邻居192.168.100.3（Telluride）的EBGP消息源自其Loopback0接口，并且配置了静态路由以通过全部四条物理链路发现邻居地址
router bgp 400
no synchronization
bgp log-neighbor-changes
neighbor 192.168.100.3 remote-as 100
neighbor 192.168.100.3 disable-connected-check
neighbor 192.168.100.3 update-source Loopback0
no auto-summary
!
ip route 192.168.100.3 255.255.255.255 192.168.1.206
ip route 192.168.100.3 255.255.255.255 192.168.1.210
ip route 192.168.100.3 255.255.255.255 192.168.1.214
ip route 192.168.100.3 255.255.255.255 192.168.1.218从例2-19可以看出，Alta到Telluride的邻居状态为Idle，进一步检查后可以发现（位于输出结果底部），由于邻居地址192.168.100.3非直连，因而没有处于激活状态的TCP会话，这就是IOS默认为EBGP邻居执行的直连检查。
例2-19 由于IOS的默认直连检查表明地址未直连本地子网，因而到Telluride的邻居状态是Idle
Alta#show ip bgp neighbor 192.168.100.3
BGP neighbor is 192.168.100.3, remote AS 100, external link
BGP version 4, remote router ID 0.0.0.0
BGP state = Idle
Last read 00:00:00, last write 00:00:00, hold time is 180, keepalive interval is
60 seconds
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 0 0
Notifications: 0 0
Updates: 0 0
Keepalives: 0 0
Route Refresh: 0 0
Total: 0 0
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP table version 1, neighbor version 0/0
Output queue size: 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0
Connections established 0; dropped 0
Last reset never
External BGP neighbor not directly connected.
No active TCP connection
Alta#如果外部BGP邻居是直连邻居，但邻居地址不属于本地子网（这是在环回接口之间建立EBGP对等会话时的最常见情形），那么就可以利用neighbor disable-connected-check语句禁用IOS的直连检查特性。例2-20给出了使用该语句的Alta配置信息，Telluride的配置中也增加了该语句，例2-21的输出结果表明目前已经在两个环回地址之间建立了BGP会话。
例2-20 Alta的EBGP配置中包含了neighbor disable-connected-check语句
router bgp 400
no synchronization
bgp log-neighbor-changes
neighbor 192.168.100.3 remote-as 100
neighbor 192.168.100.3 disable-connected-check
neighbor 192.168.100.3 update-source Loopback0
no auto-summary
!
ip route 192.168.100.3 255.255.255.255 192.168.1.206
ip route 192.168.100.3 255.255.255.255 192.168.1.210
ip route 192.168.100.3 255.255.255.255 192.168.1.214
ip route 192.168.100.3 255.255.255.255 192.168.1.218例2-21 禁用了直连检查特性之后，Alta与Telluride之间的EBGP会话已经建立了
Alta#show ip bgp neighbor 192.168.100.3
BGP neighbor is 192.168.100.3, remote AS 100, external link
BGP version 4, remote router ID 192.168.100.3
BGP state = Established, up for 00:10:06
Last read 00:00:05, last write 00:00:05, hold time is 180, keepalive interval is
60 seconds
Neighbor capabilities:
[Remaining output deleted]图2-30描绘了另一种常见的EBGP对等场景，此时的EBGP会话仍然运行在Alta与Telluride的环回接口之间，但这两台路由器并未直连，此时的EBGP会话必须穿越路由器Copper，而Copper却根本就没有运行BGP。Copper可能是一台过滤路由器或其他安全设备，在允许数据包进入AS100之前检查所有的数据包。Copper也可能是众多将EBGP会话聚合为一条会话的边缘路由器中的一台，或者是AS100的内部路由器。此时仅仅禁用IOS的直连检查机制还不够，这是因为发送EBGP消息时的TTL默认值为1，从Alta经Copper到达Telluride的数据包的TTL至少为2，因为数据包穿越Copper时其TTL将被递减1。
图2-30 两台非直连路由器的EBGP对等会话场景
neighbor ebgp-multihop语句可以更改发送给指定邻居的EBGP消息的默认TTL值，例2-22给出了图2-30中的三台路由器的配置示例，在Telluride与Copper之间配置了OSPF以实现简单的可达性，在Copper上为Alta的环回地址配置了静态路由，并在Alta上配置了一条指向Copper的静态默认路由。最重要的是，Copper并没有运行BGP。Telluride和Alta使用了neighbor ebgp-multihop语句，将它们的EBGP消息的默认TTL值更改为2，EBGP消息穿越Copper后，其TTL将被递减至1，因而能够安全抵达目的端。如果在发送EBGP消息时仍然将TTL值保持为1，那么这些数据包的TTL将在Copper处被递减至0，导致数据包被丢弃。
例2-22 图2-30中的路由器Telluride和Alta被配置为穿越两个路由器跳建立EBGP会话
Telluride
router ospf 1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 192.168.200.1 remote-as 400
neighbor 192.168.200.1 ebgp-multihop 2
neighbor 192.168.200.1 update-source Loopback0
no auto-summary
!
Copper
router ospf 1
log-adjacency-changes
redistribute static
network 0.0.0.0 255.255.255.255 area 0
!
ip route 192.168.200.0 255.255.255.0 192.168.1.222
!
Alta
router bgp 400
no synchronization
bgp log-neighbor-changes
neighbor 192.168.100.3 remote-as 100
neighbor 192.168.100.3 ebgp-multihop 2
neighbor 192.168.100.3 update-source Loopback0
no auto-summary
!
ip route 0.0.0.0 0.0.0.0 192.168.1.221例2-23显示Alta到Telluride邻居状态为Established，进一步查看输出结果可以看出，出站TTL已经从默认值1更改为2。
例2-23 Alta到Telluride（192.168.100.3）的邻居状态为Established
Alta#show ip bgp neighbor 192.168.100.3
BGP neighbor is 192.168.100.3, remote AS 100, external link
BGP version 4, remote router ID 192.168.100.3
BGP state = Established, up for 00:26:41
Last read 00:00:41, last write 00:00:41, hold time is 180, keepalive interval is
60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 0 0
Keepalives: 28 28
Route Refresh: 0 0
Total: 29 29
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP table version 1, neighbor version 1/0
Output queue size: 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0
Connections established 1; dropped 0
Last reset never
External BGP neighbor may be up to 2 hops away.
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 2
Local host: 192.168.200.1, Local port: 179
Foreign host: 192.168.100.3, Foreign port: 29761
Connection tableid (VRF): 0
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x22885C):
Timer Starts Wakeups Next
Retrans 29 0 0x0
TimeWait 0 0 0x0
AckHold 29 1 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
Linger 0 0 0x0
ProcessQ 0 0 0x0
iss: 3118002936 snduna: 3118003514 sndnxt: 3118003514 sndwnd: 16346
irs: 3626178200 rcvnxt: 3626178778 rcvwnd: 16346 delrcvwnd: 38
SRTT: 294 ms, RTTO: 345 ms, RTV: 51 ms, KRTT: 0 ms
minRTT: 36 ms, maxRTT: 312 ms, ACK hold: 200 ms
Status Flags: passive open, gen tcbs
Option Flags: nagle
IP Precedence value : 6
Datagrams (max data segment is 536 bytes):
Rcvd: 58 (out of order: 0), with data: 29, total data bytes: 577
Sent: 31 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0),
with data: 28, total data bytes: 577
Packets received in fast path: 0, fast processed: 0, slow path: 0
fast lock acquisition failures: 0, slow path: 0
Alta#大家可能会疑惑为什么没在上述配置中增加neighbor disable-connected-check语句，很明显Alta与Telluride并非直连，而且它们的环回地址也不属于同一个子网，而例2-23又显示这两台路由器的环回接口之间的EBGP会话已经建立。答案就在于使用neighbor ebgp-multihop语句增加TTL的时候，会自动禁用直连检查机制。
利用neighbor ebgp-multihop语句将TTL更改为2或更大值，可以让图2-29中的场景进行正常工作，在效果上与使用neighbor disable-connected-check语句相同。这里可能会产生误解，将数据包发送给邻居路由器的IP地址时，如果目的地址不属于本地直连子网，那么就应该递减TTL值，但实际情况却并非如此，仅当数据包离开路由器（真正的路由器跳）时，才会递减IP包的TTL值。
因此，如果希望与直连路由器上某个不属于直连子网的IP地址建立EBGP会话（见图2-29），那么就可以使用neighbor disable-connected-check语句，这样就可以在不更改默认TTL行为的情况下建立连接。如果必须要与间隔多于一个路由器跳的邻居建立EBGP会话，那么就可以使用neighbor ebgp-multihop语句，但是应该仅允许到达邻居所必需的路由器跳数。
到目前为止的案例已经解释了配置全功能BGP会话所需的所有信息，而且也解释了查看以及检测与排除BGP会话故障所需的常见工具，但是还有一些更丰富的配置特性可以让BGP会话更加可管，也更加安全，虽然这些特性对于BGP会话的建立以及运行来说并非必不可少。
注：
除了本例解释的功能特性之外，BGP对等体组以及对等体模板也能让大型BGP配置更加可管，有关对等体组和对等体模板的详细信息将在第5章作为扩展特性进行讨论，这是因为随着配置复杂性的不断增加，这些分组工具不但便捷，而且对于配置控制来说必不可少。
例2-24给出了图2-27中的路由器Vail的BGP配置信息，例中增加了一些常见的管理和安全特性。
例2-24 在Vail（见图2-27）的BGP配置中增加了一些常见的管理和安全特性
router bgp 100
bgp router-id 192.168.100.1
bgp log-neighbor-changes
neighbor 192.168.1.225 remote-as 200
neighbor 192.168.1.225 description Taos
neighbor 192.168.1.225 password N0rdic
neighbor 192.168.1.225 ttl-security hops 1
neighbor 192.168.100.2 remote-as 100
neighbor 192.168.100.2 description Aspen
neighbor 192.168.100.2 password aLpine
neighbor 192.168.100.2 update-source Loopback0
neighbor 192.168.100.3 remote-as 100
neighbor 192.168.100.3 description Telluride
neighbor 192.168.100.3 password aLpine
neighbor 192.168.100.3 update-source Loopback0
neighbor 192.168.100.10 remote-as 100
neighbor 192.168.100.10 description Whistler
neighbor 192.168.100.10 password aLpine
neighbor 192.168.100.10 shutdown
neighbor 192.168.100.10 update-source Loopback0
!Vail配置中的第一条新语句就是bgp router-id。如前所述，IOS在获得BGP路由器ID时的处理进程与OSPF路由器ID相同：如果存在环回接口地址，那么就使用环回接口地址；否则就使用数值最大的物理接口地址。bgp router-id语句可以忽略该自动进程，允许手工分配BGP路由器ID，如果希望BGP路由器ID与环回接口地址不同，那么就可以使用该语句，或者利用该命令确保BGP路由器ID保持稳定和可预测（如本例所示），即使增加、更改或删除了环回地址。
例2-24中的另一条新语句就是bgp log-neighbor-changes。由于目前所有的最新IOS版本都默认启用该功能特性，因而创建BGP的配置时，将自动输入该语句。不过，由于该语句也是一种非常关键的排障工具，因而最好检查BGP配置以确定输入了该语句。如果邻居状态发生了变化，那么该功能特性就能将变化情况以及变化原因记录到路由器的日志缓存（如果配置了syslog，那么就可以记录到syslog服务器）中。
利用show logging命令可以显示日志缓存中的表项信息（见例2-25），本例中的日志表项 （位于日志缓存信息之后）反映了Vail的一些邻居事件，第一条表项记录了与邻居192.168.100.3（图2-27中的Telluride）建立了邻接关系，第二条表项表明该邻接关系大约在4分钟之后出现中断，而且更重要的是，该表项同时记录了邻接关系出现中断的原因：Telluride关闭了会话。从这个信息就可以知道该会话关闭的原因是BGP主动行为，而不是出现了“硬”故障。从第三条表项可以知道，1分钟之后，Vail又重新与Telluride建立了邻接关系。
例2-25 bgp log-neighbor-changes语句可以记录BGP邻居状态的变化情况，然后可以利用show logging命令显示相关信息
Vail#show logging
Syslog logging: enabled (10 messages dropped, 0 messages rate-limited,
0 flushes, 0 overruns, xml disabled, filtering disabled)
No Active Message Discriminator.
No Inactive Message Discriminator.
Console logging: level debugging, 505 messages logged, xml disabled,
filtering disabled
Monitor logging: level debugging, 0 messages logged, xml disabled,
filtering disabled
Buffer logging: level debugging, 505 messages logged, xml disabled,
filtering disabled
Logging Exception size (8192 bytes)
Count and timestamp logging messages: disabled
No active filter modules.
ESM: 0 messages dropped
Trap logging: level informational, 509 message lines logged
Log Buffer (8192 bytes):
*Aug 21 07:11:38: %BGP-5-ADJCHANGE: neighbor 192.168.100.3 Up
*Aug 21 07:15:16: %BGP-5-ADJCHANGE: neighbor 192.168.100.3 Down Peer closed the
session
*Aug 21 07:16:17: %BGP-5-ADJCHANGE: neighbor 192.168.100.3 Up
*Aug 21 07:19:35: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed
state to up
*Aug 21 07:21:03: %TCP-6-BADAUTH: No MD5 digest from 192.168.1.225(179) to
192.168.1.226(20308)
*Aug 21 07:21:04: %TCP-6-BADAUTH: No MD5 digest from 192.168.1.225(179) to
192.168.1.226(20308)
*Aug 21 07:21:04: %TCP-6-BADAUTH: No MD5 digest from 192.168.1.225(179) to
192.168.1.226(20308)
*Aug 21 07:21:06: %TCP-6-BADAUTH: No MD5 digest from 192.168.1.225(179) to
192.168.1.226(20308)
*Aug 21 07:21:09: %TCP-6-BADAUTH: No MD5 digest from 192.168.1.225(179) to
192.168.1.226(20308)
*Aug 21 07:21:14: %TCP-6-BADAUTH: No MD5 digest from 192.168.1.225(179) to
192.168.1.226(20308)
Vail#第四条表项显示接口S1/0的状态已经更改为Up，其中，接口S1/0连接了Taos（192.168.1.225）（见图2-27）。该接口状态变为Up之后，后面的表项表明Vail一直重复尝试在端口179上与Taos打开TCP连接，但是从这些表项可以知道，这些尝试均因为认证问题而失败。
认证问题又引出了Vail配置的另一个新功能特性：neighbor password语句可以为邻居启用MD5认证并指定密码[13]。从例2-25的日志表项可以看出，Vail配置了MD5认证，而Taos则未配置MD5认证。如果Taos配置了认证，但是密码却与Vail的不匹配，那么日志表项就是“Invalid MD5 digest（无效的MD5摘要）”，而不是“No MD5 digest（无MD5摘要）”。
例2-24中的每个Vail邻居都配置了认证机制。与IGP一样，必须认证所有的IBGP会话，但是认证EBGP会话不仅非常重要，而且也是保护网络的必备需求，绝大多数面向路由协议的攻击尝试都是针对EBGP的，由于EBGP是暴露在“外部网络”的协议，因而是最容易访问的协议。需要记住的是，永远不要在无认证的情况下运行EBGP。
例2-24表明所有的IBGP邻居都配置了相同的密码（aLpine），而外部邻居Taos则配置了不同的密码（N0rdic）。与IGP一样，为所有的IBGP会话使用相同的密码在管理上较为简单，也是可接受的，但应该为每个EBGP会话设置不同的密码。有时网络管理员会为同一个邻接管理域的多个EBGP会话使用相同的密码，仅为不同的域使用不同的密码。最安全的实践方式是为所有的EBGP会话（无论哪个域）都使用不同的密码。
从Vail对Taos的EBGP会话配置中可以看到另一个EBGP安全特性：neighbor ttl-security。为了更好地理解该语句的作用，将例2-26中的高亮显示部分（启用了neighbor ttl-security语句）与例2-8中的相应输出行（未启用该安全特性）进行比较后可以发现，例2-8中Vail对Taos的邻居数据库显示的IOS默认TTL行为与EBGP多跳案例研究中讨论的情况一样：入站BGP消息包的TTL可以为0或更大（是本地路由器将接收到的数据包的TTL值递减之后的TTL值），路由器将自己发起的BGP消息包的TTL值设为1。在Vail的BGP配置中指定neighbor 192.168.1.225 ttl-security hops 1语句之后会对默认行为造成以下两个变化（见例2-26）：
例2-26 neighbor ttl-security功能特性会改变接收到的EBGP消息包的可接受TTL值以及发送的BGP消息包的TTL值
Vail#show ip bgp neighbor 192.168.1.225
BGP neighbor is 192.168.1.225, remote AS 200, external link
BGP version 4, remote router ID 192.168.1.225
BGP state = Established, up for 00:00:31
Last read 00:00:30, last write 00:00:00, hold time is 180, keepalive interval
is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 6 6
Notifications: 0 0
Updates: 0 0
Keepalives: 75 77
Route Refresh: 0 0
Total: 81 83
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP table version 1, neighbor version 0/0
Output queue size: 0
Index 2, Offset 0, Mask 0x4
2 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0
Connections established 6; dropped 5
Last reset 00:00:34, due to User reset
External BGP neighbor may be up to 1 hop away.
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 254, Outgoing TTL 255
Local host: 192.168.1.226, Local port: 13408
Foreign host: 192.168.1.225, Foreign port: 179
Connection tableid (VRF): 0
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x3D55F8):
Timer Starts Wakeups Next
Retrans 4 0 0x0
TimeWait 0 0 0x0
AckHold 2 1 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
Linger 0 0 0x0
ProcessQ 0 0 0x0
iss: 379206806 snduna: 379206890 sndnxt: 379206890 sndwnd: 16301
irs: 3498356006 rcvnxt: 3498356109 rcvwnd: 16282 delrcvwnd: 102
SRTT: 206 ms, RTTO: 1891 ms, RTV: 1685 ms, KRTT: 0 ms
minRTT: 400 ms, maxRTT: 608 ms, ACK hold: 200 ms
Status Flags: active open
Option Flags: nagle, md5
IP Precedence value : 6
Datagrams (max data segment is 1440 bytes):
Rcvd: 4 (out of order: 0), with data: 2, total data bytes: 102
Sent: 6 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0)
with data: 3, total data bytes: 83
Packets received in fast path: 0, fast processed: 0, slow path: 0
fast lock acquisition failures: 0, slow path: 0
Vail#虽然将发起的数据包的TTL值设为1的默认行为可以确保数据包不会传播到直连路由器之外，但是接受TTL为0或更大值的数据包的默认行为却意味着可以向EBGP发起多种远程攻击，只要发起的攻击数据包的TTL足够大，这些数据包就能在穿越大量路由器后仍被本地路由器所接受。虽然认证机制能够从内部防止BGP接受这类数据包，但是短时间内出现的大量无效数据包会产生大量认证失败操作，从而中断EBGP会话或耗尽路由器的CPU资源，致使BGP失败，甚至出现路由器崩溃等严重后果。
将出站数据包的TTL设置为255且仅接受TTL为254或更大值的数据包，就可以确保无法从非直接连路由器向本地BGP进程发送数据包[14]。数据包穿越单台路由器之后，其TTL就从最大值255递减至254，到达本地路由器之后其TTL将被递减至253，低于可接受的最小值，因而该数据包就会在到达本地BGP进程之前被悄悄丢弃（也就是说，可以在不发送ICMP差错消息的情况下丢弃该数据包）。
当然，如果利用neighbor ttl-security特性将最小TTL值设置为254，那么邻居就必须以TTL值255来发送BGP消息包，此时就要求两台路由器都配置该特性，如果其中的某个邻居不是IOS路由器，那么也必须支持等价的功能特性。还有一个需要注意的问题，那就是neighbor ttl-security与neighbor ebgp-multihop不兼容，不过也可以通过调整neighbor ttl-security的跳数规范来达到相同的效果。
表2-6对比了EBGP多跳与TTL安全之间的差异。
表2-6 EBGP多跳与TTL安全对比
| BGP消息选项 |
入站BGP消息最小可接受的TTL |
出站BGP消息的TTL |
|---|---|---|
| 默认 |
0或更大 |
1 |
| neighbor ebgp-multihop |
0或更大 |
指定的TTL值 |
| neighbor ttl-security |
255-指定跳数值 |
255 |
例2-24配置文件中另一个新语句就是neighbor description，该语句对于BGP没有功能上的效应，只是为邻居地址提供了一种最多80个字符的文字描述，能够在配置中更容易地标识邻居。
最后，例2-24给出了新邻居Whistler（192.168.100.10）的配置信息，但是由于此时还没有安装Whistler，因而利用neighbor shutdown语句来防止Vail试图连接不存在的邻居。如果希望禁用指定邻居的连接，但是又不希望删除该邻居的配置，那么neighbor shutdown语句就显得非常有用。
本章全面讨论了BGP对等会话以及底层TCP会话的配置方式以及故障检测与排除技术，但是读者一定发现了本章并没有解释如何通过这些会话传递路由信息，因而下一章将详细讨论通过BGP会话发送和接收路由信息的相关技术，以及利用路由策略改变路由信息的使用方式。
1．什么是不可信管理域？为什么不可信？
2．BGP与IGP在对等会话方面的差异是什么？
3．哪些AS号被保留用作私有用途？
4．四种BGP消息类型分别是哪些？它们的使用方式是什么？
5．如果两个BGP邻居在Open消息中宣告的保持时间不同，那么会怎么样？
6．协商后的保持时间为0意味着什么？
7．IOS发送BGP Keepalive消息的默认周期是什么？
8．什么是BGP标识符？如何选择？
9．BGP对等体在哪种或哪些状态下可以交换Update消息？
10．什么是NLRI？
11．什么是路径属性？
12．什么是被撤销路由？
13．收到BGP Notification消息之后会怎么样？
14．Connect状态与Active状态之间的区别是什么？
15．什么情况下会迁移到OpenConfirm状态？如果BGP进程显示邻居处于OpenConfirm状态下，那么下一步是什么？
16．BGP路径属性包括哪四类？
17．周知强制属性的含义是什么？三种周期强制路径属性分别是什么？
18．ORIGIN属性的作用是什么？
19．AS_PATH属性的作用是什么？
20．路由器在何种情况下会将自己的AS号添加到Update消息的AS_PATH列表中？
21．什么是AS路径预附加？
22．什么是AS_SEQUENCE和AS_SET？两者有何区别？
23．NEXT_HOP属性的作用是什么？
24．什么是递归路由查找？为何递归路由查找对于BGP非常重要？
25．如果路由器收到的BGP路由的NEXT_HOP地址对于该路由器来说未知，那么会出现什么情况？
26．BGP RIB包括哪三个部分？它们的功能分别是什么？
27．BGP Update消息中的NLRI都有什么共同之处？
28．BGP在宣告IPv6前缀时需要在IPv6地址之间建立TCP连接吗？
29．发送给外部对等体的BGP消息包的IOS默认TTL值是多少？
表2-7列出了配置练习题1～4将要用到的自治系统、路由器、接口以及地址等信息。表中列出了所有路由器的接口情况，为了符合可用资源情况，解决方案的物理接口可能会发生变化。对于每道练习题来说，如果表中显示该路由器有环回接口，那么该接口就是所有IBGP连接的源端。除非练习题有明确约定，否则EBGP连接始终位于物理接口地址之间。此外，所有的邻居描述均被配置为路由器的名称。
表2-7 配置练习题1～4用到的配置信息
1．将OSPF配置为AS1的IGP，OPSF area 0跨越整个AS。不应该将AS1的内部路由宣告到AS之外，不应该将所有运行了EBGP的点到点链路宣告到AS内。然后将AS1配置为全网状IBGP，将所有的IBGP连接都配置为使用密码Ch2_ExcerSizE1的MD5认证。
2．在AS1的R1与AS2的R4之间配置EBGP对等会话，利用密码Ch2_ExcerSizE2认证该EBGP对等会话。手工将R4的router-id设置为Loopback 1的IP地址。此外，要通过控制TTL值来确保这两台路由器的安全，防范远程攻击。
3．在AS1的R3与AS3的R5之间配置EBGP对等会话（利用路由器上配置的IPv6点到点物理地址），并能够记录这两台路由器的所有邻居状态变化情况。
4．在AS1的R2与AS4的R6之间配置EBGP对等会话，以便通过两条物理链路实现负载共享。不使用链路聚合，在R2和R6上使用静态路由。
1．图2-31中的路由器R1和R3相互之间能够ping通对方的Loopback 0接口，网络维护人员在这两台路由路由器之间配置了IBGP对等会话（见例2-27），但是没能建立IBGP会话。这两台路由器都配置了命令bgp log-neighbor-changes，而且例2-28给出了show logging和show ip bgp neighbors命令的输出结果。请问IBGP会话未成功建立的原因是什么？
图2-31 故障检测与排除练习题1的拓扑结构
例2-27 在R1与R3之间配置IBGP对等会话
! R1
!
router bgp 1
bgp log-neighbor-changes
neighbor 192.168.0.3 remote-as 1
neighbor 192.168.0.3 update-source loopback 0
neighbor 192.168.0.3 description R3
neighbor 192.168.0.3 password Ch2_Troublesh00ting_ExcerSizE
!
________________________________________________________________________
! R3
!
router bgp 1
bgp log-neighbor-changes
neighbor 192.168.0.1 remote-as 1
neighbor 192.168.0.1 update-source loopback 0
neighbor 192.168.0.1 description R1
neighbor 192.168.0.1 password Ch2_Troublesh00ting_ExcerSizE
!例2-28 show logging和show ip bgp neighbors命令的输出结果
R1
R1#<strong>show logging</strong>
Syslog logging: enabled (12 messages dropped, 9 messages rate-limited,
0 flushes, 0 overruns, xml disabled, filtering disabled)
No Active Message Discriminator.
No Inactive Message Discriminator.
Console logging: level debugging, 117 messages logged, xml disabled,
filtering disabled
Monitor logging: level debugging, 0 messages logged, xml disabled,
filtering disabled
Buffer logging: level debugging, 126 messages logged, xml disabled,
filtering disabled
Logging Exception size (8192 bytes)
Count and timestamp logging messages: disabled
Persistent logging: disabled
No active filter modules.
ESM: 0 messages dropped
Trap logging: level informational, 59 message lines logged
Log Buffer (8192 bytes):
*Sep 4 01:21:00.311: %SYS-5-CONFIG_I: Configured from console by console
*Sep 4 01:21:20.835: BGP: 192.168.0.3 went from Idle to Active
*Sep 4 01:21:20.843: BGP: 192.168.0.3 open active delayed 30866ms (35000ms max, 28%
jitter)
*Sep 4 01:21:51.711: BGP: 192.168.0.3 open active, local address 192.168.0.1
*Sep 4 01:21:51.891: BGP: 192.168.0.3 open failed: Destination unreachable; gateway
or host down, open active delayed 31701ms (35000ms max, 28% jitter)
*Sep 4 01:22:23.595: BGP: 192.168.0.3 open active, local address 192.168.0.1
R1#<strong>show ip bgp neighbors</strong>
BGP neighbor is 192.168.0.3, remote AS 1, internal link
BGP version 4, remote router ID 0.0.0.0
BGP state = Active
Last read 00:03:33, last write 00:03:33, hold time is 180, keepalive interval is
60 seconds
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 0 0
Notifications: 0 0
Updates: 0 0
Keepalives: 0 0
Route Refresh: 0 0
Total: 0 0
Default minimum time between advertisement runs is 0 seconds
For address family: IPv4 Unicast
BGP table version 1, neighbor version 0/0
Output queue size: 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0
Connections established 0; dropped 0
Last reset never
No active TCP connection
________________________________________________________________________
R3
R3#<strong>show logging</strong>
Syslog logging: enabled (12 messages dropped, 9 messages rate-limited,
0 flushes, 0 overruns, xml disabled, filtering disabled)
No Active Message Discriminator.
No Inactive Message Discriminator.
Console logging: level debugging, 115 messages logged, xml disabled,
filtering disabled
Monitor logging: level debugging, 0 messages logged, xml disabled,
filtering disabled
Buffer logging: level debugging, 124 messages logged, xml disabled,
filtering disabled
Logging Exception size (8192 bytes)
Count and timestamp logging messages: disabled
Persistent logging: disabled
No active filter modules.
ESM: 0 messages dropped
Trap logging: level informational, 55 message lines logged
Log Buffer (8192 bytes):
*Sep 4 01:20:55.003: %SYS-5-CONFIG_I: Configured from console by console
*Sep 4 01:21:28.723: BGP: 192.168.0.1 went from Idle to Active
*Sep 4 01:21:28.731: BGP: 192.168.0.1 open active delayed 34023ms (35000ms max, 28%
jitter)
*Sep 4 01:22:02.755: BGP: 192.168.0.1 open active, local address 192.168.0.3
*Sep 4 01:22:02.811: BGP: 192.168.0.1 open failed: Destination unreachable; gateway
or host down, open active delayed 25843ms (35000ms max, 28% jitter)
*Sep 4 01:22:28.655: BGP: 192.168.0.1 open active, local address 192.168.0.3
*Sep 4 01:22:28.831: BGP: 192.168.0.1 open failed: Destination unreachable; gateway
or host down, open active delayed 27833ms (35000ms max, 28% jitter)
*Sep 4 01:22:56.667: BGP: 192.168.0.1 open active, local address 192.168.0.3
*Sep 4 01:22:56.859: BGP: 192.168.0.1 open failed: Destination unreachable; gateway
or host down, open active delayed 33383ms (35000ms max, 28% jitter)
R3#<strong>show ip bgp neighbors</strong>
BGP neighbor is 192.168.0.1, remote AS 1, internal link
BGP version 4, remote router ID 0.0.0.0
BGP state = Active
Last read 00:03:57, last write 00:03:57, hold time is 180, keepalive interval is
60 seconds
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 0 0
Notifications: 0 0
Updates: 0 0
Keepalives: 0 0
Route Refresh: 0 0
Total: 0 0
Default minimum time between advertisement runs is 0 seconds
For address family: IPv4 Unicast
BGP table version 1, neighbor version 0/0
Output queue size: 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0
Connections established 0; dropped 0
Last reset never
No active TCP connection2．虽然在图2-32中的R1和R2之间配置了IBGP连接，但是该连接并没有建立完成。检查日志缓存后发现日志信息如例2-29所示。请问IBGP会话未成功建立的原因是什么？
图2-32 故障检测与排除练习题2的拓扑结构
例2-29 日志中缺少IBGP会话信息
R1#
*Sep 4 02:49:20.575: BGP: 192.168.0.2 open failed: Connection timed out; remote
host not responding, open active delayed 457ms (1000ms max, 87% jitter)
*Sep 4 02:49:21.035: BGP: 192.168.0.2 open active, local address 192.168.0.1
R1#
*Sep 4 02:49:21.287: %TCP-6-BADAUTH: No MD5 digest from 192.168.0.2(179) to
192.168.0.1(43661)3．在排查练习题2中的问题时，网络维护人员更改了其中一台路由器的BGP配置信息，之后收到的日志消息如例2-30所示。请问IBGP会话未成功建立的原因是什么？本练习题与练习题2的日志消息有何区别？
例2-30 日志仍然没有IBGP会话信息
R1#
*Sep 4 02:51:16.003: BGP: 192.168.0.2 open active, local address 192.168.0.1
R1#
*Sep 4 02:51:21.007: BGP: 192.168.0.2 open failed: Connection timed out; remote
host not responding, open active delayed 30634ms (35000ms max, 28% jitter)
R1#
*Sep 4 02:51:21.739: %TCP-6-BADAUTH: Invalid MD5 digest from 192.168.0.2(28677) to
192.168.0.1(179)4．如图2-33所示，路由器R1和R2位于AS1中，R3位于AS2中，AS1的IGP是OSPF且area 0跨越整个AS。路由器R1和R2被配置为通过各自的环回地址进行对等连接，R1与R3之间通过物理链路地址进行对等连接，这三台路由器的配置信息如例2-31所示。虽然路由器R2的show ip bgp输出结果中显示了R3的接口Loopback0（192.168.0.3），但是并没有在IP路由表中安装该路由，其原因是什么？解决该问题的两种方案分别是什么？哪种解决方案是最佳实践配置？
图2-33 故障检测与排除练习题4的拓扑结构
例2-31 故障检测与排除练习题4的路由器配置
! R1
!
interface Serial1/0
ip address 10.0.0.1 255.255.255.252
!
interface Serial1/1
ip address 172.16.0.1 255.255.255.252
!
interface Loopback 0
ip address 192.168.0.1 255.255.255.255
!
router ospf 1
log-adjacency-changes
network 10.0.0.1 0.0.0.0 area 0
network 192.168.0.1 0.0.0.0 area 0
!
router bgp 1
no synchronization
bgp log-neighbor-changes
neighbor 192.168.0.2 remote-as 1
neighbor 192.168.0.2 update-source Loopback0
neighbor 172.16.0.2 remote-as 2
no auto-summary
!
________________________________________________________________________
! R2
!
interface Serial1/0
ip address 10.0.0.2 255.255.255.252
!
interface Loopback 0
ip address 192.168.0.2 255.255.255.255
!
router ospf 1
log-adjacency-changes
network 10.0.0.2 0.0.0.0 area 0
network 192.168.0.2 0.0.0.0 area 0
!
router bgp 1
no synchronization
bgp log-neighbor-changes
neighbor 192.168.0.1 remote-as 1
neighbor 192.168.0.1 update-source Loopback0
no auto-summary
!
________________________________________________________________________
! R3
!
interface Serial1/1
ip address 172.16.0.2 255.255.255.252
!
interface Loopback 0
ip address 192.168.0.3 255.255.255.255
!
router bgp 2
no synchronization
bgp log-neighbor-changes
network 192.168.0.3 mask 255.255.255.255
neighbor 172.16.0.1 remote-as 1
no auto-summary
!5．参考故障检测与排除练习题4中的图2-33，网络维护人员解决了无法在R2上将BGP路由安装到IP路由表中的问题之后，目前BGP表与IP路由表中均有该路由，但此时从R2到R3的ping操作仍然失败，那么原因是什么？如何解决？
[1] 本例显示的是俄勒冈大学公共路由服务器2014年的数据，本书第一版的示例取自AT&T路由服务器1999年的数据，当时显示的BGP路由数量是88269条。
[2] 从两个源端接收全部BGP路由将会使所有路由器的BGP路由数量加倍，导致内存需求也加倍。
[3] 早期的IOS文档将该参数称为管理权重（Administrative Weight），最新的文档已经不再使用该术语，转而使用权重。这么做的原因可能是为了避免与管理距离（Administrative Distance）相混淆，管理距离是一个完全不同且与协议无关的参数。
[4] 由于不同设备商的BGP决策进程可能会存在一些差异，因而在多厂商的BGP网络环境下，必须理解每个厂商的BGP决策进程步骤。由于BGP决策进程会随着新功能特性的加入而发生变化，因而即便是IOS，早期版本与新版本之间也可能会存在细微差异。
[5] IOS为默认MED行为提供了两种替代方案：bgp deterministic-med和bgp alwayscompare-med，有关这些替代方案的详细内容请参阅第4章。
[6] RFC 1771及以前就出现了不可行路由长度，虽然RFC 4271更改了不可行路由长度的名称，但功能上完全相同。
[7] 由于BGP经常增加新的属性，因而本表可能并不完整。
[8] 为了简化输出结果，本书中的调试示例均关闭了时间戳特性，除非时间差对于示例本身非常重要。不过，对于生产性网络来说，时间戳是调试以及其他日志功能的重要组成部分，必须打开该特性。
[9] 还可以利用show bgp neighbors命令显示相同信息，不过IOS手册中并没有记录该命令，而且并不是所有的IOS版本均支持该命令。此外，show ip bgp neighbors命令在不同IOS版本下的输出结果可能会存在一些差别。
[10] 如果部署了路由反射器（见第5章），那么就要调整本规则。
[11] 也可以使用show bgp summary命令显示相同信息，虽然未在IOS手册中记录该命令，而且也可能并不是所有的IOS版本均支持该命令。show bgp summary命令的输出结果与具体的IOS版本有关。
[12] 另一种解决方案就是利用链路聚合协议“捆绑”这些链路，这样就不需要配置EBGP多跳或禁用直连检查。
[13] 一般来说，显示在配置中的认证密码与其他密码一样，都应该进行加密。对于本例来说，由于禁用了密码加密功能，因而能够看到该密码。
[14] 通过控制TTL来防范攻击行为的方式称为GTSM（Generalized TTL Security Mechanism，通用TTL安全机制），定义在RFC 3682中。
