OSPF和IS-IS详解

978-7-115-34788-6
作者: 【美】Jeff Doyle
译者: 孙余强
编辑: 傅道坤王旭丹

图书目录:

详情

本书是在大型网络中部署OSPF和IS-IS协议的权威指南,作者以对比的方式讲解了如何在部署大型网络时分别实施OSPF和IS-IS协议,并从这两种协议的可扩展性、可靠性,以及安全性等方面给出了契合实际的建议和答案。

图书摘要

PEARSON

OSPF和IS-IS详解

OSPF and IS-IS

Choosing an IGP for Large-Scale Networks

[美]Jeff Doyle 著

孙余强 译

人民邮电出版社

北京

图书在版编目(CIP)数据

OSPF和IS-IS详解/(美)多伊尔(Doyle,J.)著;孙余强译.--北京:人民邮电出版社,2014.5

ISBN 978-7-115-34788-6

Ⅰ.①O… Ⅱ.①多…②孙… Ⅲ.①互联网络—路由协议—指南 Ⅳ.①TN915.05-62

中国版本图书馆CIP数据核字(2014)第039719号

版权声明

Jeff Doyle:OSPF and IS-IS:Choosing an IGP for Large-Scale Networks

Copyright © 2006 Pearson Education,Inc.

ISBN:978-0321168795

All rights reserved.No part of this publication may be reproduced,stored in a retrieval system,or transmitted in any form or by any means,electronic,mechanical,photocopying,recording,or otherwise without the prior consent of Addison Wesley.

版权所有。未经出版者书面许可,对本书任何部分不得以任何方式或任何手段复制和传播。

本书中文简体字版由人民邮电出版社经Pearson Education,Inc.授权出版。版权所有,侵权必究。

本书封面贴有Pearson Education(培生教育出版集团)激光防伪标签。无标签者不得销售。

◆著 [美]Jeff Doyle

译 孙余强

责任编辑 傅道坤

责任印制 彭志环 杨林杰

◆人民邮电出版社出版发行  北京市丰台区成寿寺路11号

邮编 100164  电子邮件 315@ptpress.com.cn

网址 http://www.ptpress.com.cn

大厂聚鑫印刷有限责任公司印刷

◆开本:800×1000 1/16

印张:30.5

字数:634千字  2014年5月第1版

印数:1-3000册  2014年5月河北第1次印刷

著作权合同登记号 图字:01-2012-3156号

定价:99.00元

读者服务热线:(010)81055410 印装质量热线:(010)81055316

反盗版热线:(010)81055315

内容提要

本书是在大型网络中部署OSPF和IS-IS协议的权威指南,作者以对比的方式讲解了如何在部署大型网络时分别实施OSPF和IS-IS协议,并从这两种协议的可扩展性、可靠性,以及安全性等方面给出了契合实际的建议和答案。

关于作者

Jeff Doyle,IP路由协议、MPLS及IPv6技术专家,主持或参与设计过的大型IP服务提供商网络遍及北美、欧洲、日本、韩国及中国大陆。Jeff 是《TCP/IP 路由技术》第1卷和第2卷的作者,同时还是Juniper Networks Routers:The Complete Reference一书的编辑及特约作者。他代表 Juniper 公司出席过无数场企业研讨会,并同时在 NANOG、JANOG、APRICOT 以及IPv6论坛会议上发表过多次演讲。

加盟Juniper公司之前,Jeff在International Network Services公司任资深网络系统咨询顾问一职,自那时起,他就开始专攻 IP 路由协议的设计。Jeff 持有孟菲斯州立大学文学学士学位,还在新墨西哥大学学习过电气工程专业。目前,Jeff与妻子和4个孩子居住在科罗拉多州丹佛市。

献辞

谨将本书献给我的父母L.H.和Louise Doyle,我爱你们。

致谢

首先要感谢Catherine Nolan以及Addison-Wesley出版社全体编辑、制作以及营销人员,感谢你们对我本人以及我迟迟不能交稿的极度容忍。还要感谢本书的项目编辑Laurie McGuire。这并不是我与 Laurie的第一次合作,和以前一样,这次她又使我的文字看起来远高于我的真实水平。

感谢本书的技术审阅团队:Eural Authement、Hannes Gredler、Dave Humphrey、Pete Moyer Mike Shand以及Rena Yang。你们都身经百战,对技术无比精通,试问还有那位作者能够请得动这样一支技术审阅“梦之队”。我还要感谢Ross Callon、Vint Cerf、Steve Crocker、Paul Goyette、Matt Kolon、Chelian Pandian、Russ White以及我在Juniper公司专业服务团队的全体同仁,感谢你们对本书某些特定章节的评审与建议。

我的妻子Sara,我的孩子Anna、Carol、James和Katherine,都是我生命中最重要的人。你们的支持与鼓励是本书成功付梓的关键;你们所带给我的爱和欢笑,对我而言,都是无价之宝。

最后,我要感谢我前几本书的所有读者,来自世界各地的宝贵意见和慷慨赞美使我万分荣幸,我希望你们也能从本书中获益。

前言

本书起源于一份PPT文档。多年来,作者就用这套PPT文档在IP运营商和服务提供商的网络设计座谈会上,来比较并对比 OSPF和 IS-IS。而这份 PPT文档则是作者日积月累,从无数次非正式的网络技术培训中积聚而成,其主要用途就是要让某些网络工程师能从容面对IS-IS,这些网络工程师都经常接触OSPF,但对IS-IS却知之不深,或一无所知。

随着大型网络数量的不断增多,迫切需要更多能同时掌握OSPF和IS-IS,且能分清以上两种协议各自特征的网络工程师。为了让网络工程师更方便地理解这方面的知识,作者把那些多年来在现场演讲以及技术研讨会中所使用的素材集结成书。本书的内容也确实包含了某些读者一贯想要弄清的问题、疑虑以及难点。作者坚信本书能够对读者的学习和工作有所帮助。

本书的读者

本书主要面向那些精通OSPF,并希望继续钻研IS-IS的网络工程师和架构师。因此,在本书的每一章节里,几乎都是OSPF的内容在前,IS-IS的内容在后。之所以把对相关主题的 OSPF 实现的介绍置于 IS-IS 实现之前,是为了让读者用已然掌握的知识先行铺垫。

本书同样适用于那些不甚精通OSPF的读者。此外,有些读者对OSPF和IS-IS这两种路由协议中的一种或两种有着一般性的了解,但都迫切希望深入研究这两种协议;还有些读者只精通IS-IS,对OSPF知之甚少(这样的人比较少见)。由于作者会在书中对OSPF和IS-IS做详尽论述,不偏不倚,因此本书亦适用于以上两类读者。

若读者对网络技术涉猎不深,但却想开拓自己在链路状态路由协议上的知识面,则可把本书作为教科书来读。本书的第2章专为这些读者而著,这一章内容为本书的后续章节打下了基础。在第2章中,作者全面介绍了路由协议的基本概念,尤其是链路状态路由协议。作者对其后各章内容也做了精心编排,以方便读者在阅读过程中由简入深。

对于那些立志参加网络技术认证(如Cisco公司CCIE认证或Juniper公司JNCIE认证)考试的读者来说,本书同样适合他们阅读。此类读者能从本书中获得为通过认证考试所必须掌握的与 OSPF 和 IS-IS 有关的基本概念。然而,本书并不包含相关配置及排障方面的内容,请读者通过其他渠道获取这方面的信息,以便更为全面地准备认证考试。本书每一章的末尾都附有若干习题,其目的是让读者在阅读下一章之前巩固并测试自己对本章内容的理解。因习题答案均可见于正文,故不再单独给出。

什么是大型数通网络

OSPF和IS-IS是仅有的两种适合在大型数通网络中运行的路由协议。但何谓大型数通网络,又该如何精确定义呢?回顾一下自计算机诞生之前就已经存在的数通网络及其相关理念,将会对此有所帮助。

当Alexander Graham Bell和Theodore Vail于1885年创立美国电话电报(American Telephone and Telegraph Company,AT&T)公司时,并没有打算提供电报服务。但二位都知道自己所构建的网络能够传输的东西不单是电话信号。除了知道像电话信号那样的信息表示方式之外,他们对其他的信息表示方式并无先见之明。电报反映出了 Bell 和Vail当时所理解的数通网络的雏形。

人们若要把信息传递到声音所不能企及的范围以外,就必须借助形形色色的广域数据通信手段。许多文明古国都使用火光信号来实现长途快速通信。在封建时期的日本,邻近的几个村庄都会在夜晚释放纸灯笼。灯笼会借“腹”中之火所产生的热空气冉冉上升,乃至明火高悬,这些村庄就以这样的方式来互报平安。在整个美国西南部,可以发现许多岩石雕刻——在岩石的侧面刻有数字和符号。这些雕刻出自几百年前生活在美国的土著人之手,其中包括猎人、士兵以及游客。尽管有一些雕刻只是人们自娱自乐,但也有许多雕刻被认为用来传递信号和消息,这都是过客们为路过此地的后来者而留。那些雕刻给数据通信带来了某些意想不到的启迪:信号本身总是固定不变,而信源和信宿(传递和接收信号的人)却总是在不停地移动。

电报网络是世界上首个利用电子数字信号(传递信息)的数通网络。毋庸置疑,虽然该网络属于广域网络——连接了多个国家,甚至通过海底电缆连接了几大洲——但就复杂性而言,它并不能算是我们现在所探讨的大型网络。在该网络内,通过人工操作,可以轻而易举地生成、传递以及接收信号,而且其维护手段,也是通过人工监控并干预。

那么,到底应该怎样给大型网络下定义呢?虽然网络所包括的节点数和链路数对此有所影响,但只根据那些数字来下定义,则未免以偏概全。相反的是,网络的规模应由其复杂程度来决定。通过人工直接干预就能管理得井井有条的网络,只能算是小型网络;也就是讲,早期的电报网络虽然在地理上横跨多个区域,但也只能视之为小型网络。在IP领域内,可以人为方式指定IP包的发送路线(routed statically),无需通过自动化管理系统来管理的网络,被称为小型网络。请读者注意上一句话中的“可”字,在一个特定的小型IP网络中,也同时有可能会运行某种动态路由协议或自动化管理软件,这也正是作者未说“‘必须’以人为方式指定IP包的发送路线”的原因所在。

随着网络的复杂程度不断增加,让其具备“自动运行”的能力,将会变得愈发重要。在一个中等规模的网络中,要想通过人工监控和干预的方式,来执行IP包的静态路由及相关网络管理工作,则未免显得不太实际。对于中等规模的 IP 网络,需要运行如 RIP这样的动态路由协议,来维护IP包在多条路径之间的转发。

然而,当网络的规模达到一定程度时,自动化系统自身的健壮性将会成为重中之重。如第2章所述,在充满“变数”的复杂网络中运行简单动态路由协议(如RIP),很有可会故障百出。那么,现在可以总结出大型网络的一个重要特征了。所谓大型网络,其内所运行的自动化管理系统需将网络本身作为一个实体来统一管理,而非只能单独管理节点间的链路。以下所列为管理大型网络所要考虑的因素:

各个节点之间复杂的交互方式;

复杂的与流量转发路径有关的设计考量(其中牵涉流量负载均衡)、流量的监控及分布方式、健壮的环路避免功能;

复杂的评判路由优劣的手段(complex link metrics);

数据传输需求的多样性;

对安全性及可靠性的严格要求。

无论网络的规模如何,OSPF和IS-IS都能轻松满足需求。这两种路由协议的核心价值就是,当运行两者的网络的规模不断增大时,两者本身在性能方面不会有丝毫折扣。尚无第三种IGP能满足世界上最大的IP网络——Internet——的路由选择需求。

IOS与JUNOS

本书通篇都以Cisco公司的IOS或Juniper公司的JUNOS来举例。但是在本书的前几章,作者会偶尔同时用以上两种OS来举例。作者的本意是要让读者理解OSPF和IS-IS协议本身,无意传授某种特定OS的配置方法。书中用IOS或 JUNOS来举例,一是因为这两种OS都是路由器操作系统,二来则是作者恰好会用,而且能够接触到这两种OS。读完本书之后,读者应该能够具备这样一种能力:只要捧起任一厂商的设备配置手册,就能轻松自如地在该厂商的设备上配置OSPF和IS-IS,并排除与这两种路由协议有关的故障。

第1章 链路状态路由协议之由来

本书的开篇方式极为特别。只要读者愿意,第1章可略过不读。若读者只准备了解OSPF和IS-IS技术方面的内容,请直接阅读第2章。本章不涉及技术内容,为非必读章节。作者之所以非要在这里说一说与链路状态路由协议有关的历史故事,理由很简单,那就是作者对某些事物的关注程度甚至还要超过网络技术,而历史正是其中之一。研究历史不但能帮助我们以正视听,而且还能使我们免遭满嘴谎言的奸商、政客以及其他奸诈小人的蒙蔽。专注于技术,通晓某些网络协议的运作方式固然是好事,但了解路由协议的历史,则既可以加深对它的理解,又能够拓展自己的知识面。此外,还能对为自己的网络甄选合适的路由协议有所帮助。退一万步来讲,研究历史也比去看那些胡编乱造的小说有趣多了。

要说链路状态路由协议的历史,就不能不提Internet及其前身ARPANET的历史,它们之间有很深的渊源。像Internet这样的大型网络的出现,带动了链路状态协议的需求和发展。因此,本章的内容实际上是Internet以及链路状态路由协议的发展简史。

1.1 星际网络

为当今Internet的诞生及发展做出过重要贡献的前辈数不胜数。但有一位名叫J.C.R.Licklider的智者做出了开创性的贡献,他为人谦逊,总让人喊他“Lick”,而不是“Licklider博士”。他也不介意别人用他的创意来争名夺利。Licklider对许多事物都有好奇心,但(据他自己而言)均属浅尝辄止。以上特质加之他在解决问题方面的天赋,促使他成为对多个领域都有深入研究的通才。其实,他只是一位心理学家,并非工程师,这也解释了一开始他在提出与计算和网络有关的创意时,为什么更偏重于两者在文化方面的作用而非技术本身。

20世纪50年代中期,Licklider在MIT(麻省理工学院)研究心理声学(psychoacoustics)时,对计算机产生了浓厚的兴趣。他以计算机为工具,对人类的认知建模。在此期间以及担任BBN(Bolt Baranek and Newman)公司(当时为一家专门从事声学工程咨询业务的公司)副总裁的任期内,他和他的弟子们一直宣扬一个理念,即要把计算机作为人类认知及通信的工具。1955年之前,Licklider还没怎么接触过计算机,但到了1960年初,他便成为此中高手,同时也是受到普遍认可的计算机科学领导者[1]。由他提出的多项开创性理论呈现在各种备忘录,以及后来的两篇重要论文(“Man-Computer Symbiosis”和“The Computer as a Communication Device”)中[2]

实时性、交互式计算处理,是 Licklider 提出的重要理论之一,发表在其论文“Man-Computer Symbiosis”中。20世纪50年代,计算由批处理来完成:人们将问题确定下来后,再编制程序,由计算机来计算答案。批处理所面临的问题恰恰是解决复杂问题的过程自身可能会改变原始问题。不可预见的变故(unforeseen alternatives)意味着重回起点,开始批处理的新轮回。Licklider 援引庞加莱的话,并概况为:“对问题来说,答案是什么并不重要,重要的是问题的本身。”(The question is not,“What is the answer?”The question is,“What is the question?”)人机实时交互,就可以随时引入问题解决过程中发现的新信息,对问题加以修正。

批处理还意味着计算机只能同时运行一个程序,每个用户需要轮流使用计算机。倘若能达成人与计算机间的实时交互,多个用户就应该可以同时使用计算机了。于是,时间共享(分时)理论成为了实时性、交互式计算理论的衍生。

Licklider在同一篇论文里,还提出了另一个理论,即把电脑作为辅助人类思考的工具。他以自身的日常工作为例,据 Licklider 测算,他的大多数行为都属于机械性劳动或文案工作:“我的思考时间有85%花在了寻找解决问题的出发点、做出决策以及学习一些有必要掌握的知识上了,寻找和获得信息的时间要远远多于消化知识。”与人类相比,计算机发现和组织信息的速度要快很多,因此,合理的人机关系应当是:由计算机来担负信息获取和数据处理的枯燥工作,让人类腾出精力,专注于引入新信息,解决新问题。

基于上述理论,他又提出了另一个名为“思维中心”的理论。要想利用计算机来获取信息,需能访问到单台计算机所存储不下的海量信息。Licklider提出的思维中心理论的主旨是,分处异地的多台计算机可以互相连网,并构成某种新型信息库。在“思维中心”内,随便哪一台计算机上的用户都能访问到另一台计算机里的信息。于是,一个重要理念——由分处异地的计算机构成的互连网络——应运而生。

其实,刊载于论文“The Computer as a Communication Device”里的上述理念的主旨,还不是要通过连网的计算机把不同地域的人与人“连接”在一起,而是要设法实现人与人之间最基本的心灵沟通。富于创造性的交互式通信要求作为载体的介质必须具有可塑性,只有如此,推理的前提方能借此而转化为结论。更为重要的是,那种介质必须是一种共有介质,如若不然,人们便无法集思广益、实验验证。Licklider把计算机视为介质,利用其来创建人脑所想象不出来的模型。“迄今为止,数量最多、最精密、也最为重要的模型当属人的思维。人类思维之丰富、可塑、经济和便利是难以匹敌的,不过在其他方面,也并非没有短板。它既无法在静止状态钻研问题,也无法重复运转。运作方式则无从知晓。重感性,轻理性。所能访问者,唯一人所知。一举一动,唯一人洞悉,唯一人操弄。”上述理念立足于人机交互的早期理论,但是引出了利用广域网来执行分布式数据处理的基本思路。

1962 年 10 月,Licklider 受雇于美国国防部高级研究计划署(Advanced Research Projects Agency,ARPA)[3],去领导其下辖的命令与控制研究室,以及行为科学处。命令与控制研究室又很快被更名为信息处理技术办(Information Processing Techniques Office,IPTO)。Licklider不仅带来了他的分时理论和人机交互理论,还为ARPA吸引来了同时代的众多顶尖计算机科学家。

尽管Licklider只在IPTO工作到1964年,但他的理念却为星际计算机网络的诞生起到了播种的作用。追随他的那些科学家则成为了ARPANET发展中的关键性人物。

对Web的早期设想

由Licklider提出的与人机交互有关的早期理论是受另一位智者Vannevar Bush的影响。Bush寓言了一种可用来加快人类认知过程(cognitive process)的机器,并将其命名为“memex”。

上述设想由Bush于1945年在其文章《诚如所思(As We Might Think)》[4]中提出。Bush所设想的叫作“memex”的机器可用来获取以微缩方式存贮的信息,他在文中写到:“memex 是一种机械化设备,人们既可以将自己看过的书、档案以及通信资料存于其内,还能快速而又灵活地进行检索。它可用作为人类记忆的扩展装置。memex包括一张书桌……其上可安置一个倾斜的半透明屏幕,用来浏览信息……还包括一个键盘、一套按键和一条控制杆……由于有多个信息投射位置,因此用户可在浏览一条信息的同时,查阅另外一条,还可以添加旁注和注释……”

上述观点极具前瞻性,但其所设想的却并非信息获取机制,而是一种链接多条信息,然后进行浏览的提议性机制:“用户在(针对信息)创建‘留痕’时,需为其命名,并插入代码本,然后可通过键盘来进行浏览。在用户面前有两条有待链接的信息,需将两者投射在相邻的浏览位置上……若用户敲击一个按键,那两条信息就会永久链接在一起……其后,无论何时,只要检索其中一条信息,就能很快调出另外一条……而且,将大量信息链接在一起,形成一条‘留痕’之后,便能以倒放、慢放或快进的方式来浏览那些信息了。这完全就像是把一些词条集结成书,但青出于蓝的是,可把任何信息通过千千万万条‘留痕’链接在一起。”

由此可知,在1945年,在那个受技术制约的岁月里,Vannevar Bush就已经预言到超文本和万维网(World Wide Web)所分别具备的信息链接和信息获取功能了。

1.2 ARPANET

ARPA于1958年创建于艾森豪威尔治下,之所以组建该机构,是要对前苏联发射的第一颗人造地球轨道卫星Sputnik(伴侣号)进行“回击”,因为当时美国已经清楚地意识到自己的科技水平落后于前苏联了。可以说,美国出于其在国际(科技水平)竞争力方面的尴尬,设立了这样一个机构,意在通过某种渠道(主要是通过大学)来投资并管理相关科研项目。

军工企业在结构方面的复杂性,加上各军种之间时常发生的激烈竞争,促使艾森豪威尔把ARPA定性为一个独立机构,由非军方人员来主持,同时在科研项目上给予了宽松的资金支持,以及较高的自由度。

接替J.C.R.Licklider作为ARPA第二、第三任领导的分别是Ivan Sutherland和Bob Taylor。Licklider在学术方面的成就——“星际网络”的理念,以及由连接成网络的分时计算机互连多个利益共同体的想法——对这两位领导影响甚深。有意思的是,Taylor 跟Licklider一样,也是研究“心理声学(psychoacoustics)”的心理学家,这也促使他对计算机科学发生了浓厚兴趣。

ARPA早期的许多科研项目都涉及导弹和卫星,这势必会与命令和控制系统有紧密联系。显而易见,计算机技术肯定会位居其中的核心地位——无论是作为工具还是作为科研对象。

因为由ARPA资助的大多数科研项目都是由美国各所高校来负责实施,所以用于科研的计算机也遍布全美。Bob Taylor的办公室连接了三台计算机,这三台机器分别位于MIT (麻省理工学院)、加州大学伯克利分校,以及加州圣莫尼卡的系统研发公司(System Development Corporation,SDC)。在他的办公室内,需要分别为每台计算机配备一台终端,而每台计算机的登录规程也各不相同。受到过Licklider启发的Taylor曾不停地反思,为什么就不能只通过一台终端来连接三台计算机呢。更为重要的是,Taylor还发现许多科研项目的研发效率越来越低,这要归咎于科研人员在对计算机使用时的重复劳动——当时,计算机分布在美国各州。比如,若 MIT 的科研人员认为 UCLA(加州大学洛杉矶分校)开发的一款程序非常好用,那么由于所使用的计算机不同,前者就得重新编写能为自己所用的该程序的新版本。要是MIT的研究人员能在UCLA的计算机上使用UCLA开发的程序,那岂不是更省事?此外,科研人员若能(通过网络)远程访问到自己需要使用的昂贵计算机,那岂不是又可大大节约成本?由 Licklider 提出的分时理念已付诸于实施,是时候实现他提出的通过网络连接多个利益共同体的想法了。

于是,1966 年,Taylor 发起了一个项目,意在开发出那样一个计算机网络,该项目获得了资金上的支持。ARPA网络——其最终的名称为ARPANET——就这样诞生了。

为该计算机网络挑选一名管理者和首席架构师,是 Taylor 的第一步工作。为此,他选择了Larry Roberts——此人来自MIT,是一位令人尊敬的年轻计算机科学家。在Taylor看来,该职位非Larry Roberts莫属:除了具备深厚的计算机科学背景之外,Larry Roberts还具有卓越的管理技能,他同时也正负责一个小型计算机联网项目,准备把 MIT 的林肯实验室计算机与位于圣莫尼卡的SDC计算机相连[5]

能集众家之所长,是 Roberts 对 ARPANET 项目的顺利完成所做出的最大贡献。ARPANET在基础架构方面的理念由三个人提出,他们是Leonard Kleinrock、Paul Baran和Donald Davies。早在20世纪60年代初,这三位在互不相识的情况下,就已经提出了相关理念。

Len Kleinrock 是 Roberts 在 MIT 的死党兼赌友,于 1962 年完成了自己的博士论文《Information Flow in Large Communication Nets》(大型通信网络内的信息流)。他的主攻方向是存储和转发网络内的排队原理(该原理后来集结成书)[6],其研究成果奠定了分组(包)交换网络。Kleinrock直接参与了ARPANET项目,为该项目开发了性能分析方法。

Paul Baran于1959年加入RAND公司,在这里,他花了5年时间来研究网络幸存技术(network survivability)[7]。他的主要研究方向并非计算机网络本身,而是用于弹道导弹系统的命令控制网络技术,以及当某些节点毁于核打击时,如何确保其他节点继续正常运作。在Baran看来,人类的神经网络系统健壮无比:在人脑发生部分损伤的情况下,神经网络系统会产生出新的神经纤维,可“绕过”受损的脑细胞。这再次表明了(计算机)网络理论起源于对人类认知的研究。集中式通信网络(如图1.1a所示)非常容易遭到摧毁,因为只需集中火力消灭其中心节点。相形之下,分散式网络(如图1.1b所示),如典型的电话网络,在冗余性方面要好很多,但尚有不足。Baran提出了分布式(distributed)网络的概念,在此类网络中没有所谓的“核心”交换节点,故而可在遭敌军摧毁的任一节点附近,重新构建新的路径。

Baran还进一步指出,消息在跨分散式网络发送时,应该以“分片”的方式来传送,他把那些“经过分片的消息”称为“消息块”。由于数据通信在本质上具有突发性,因此Baran又提出了另一个理论:允许多个消息来源同时发送消息块,以使网络内节点间的链路带宽得到更为充分的利用。那些节点都是存储并转发(消息块的)交换机,其主要用途为:确定通往消息块目的地的最佳线路(best route),并尽快转发——Baran将交换机的上述行为称为热土豆路由(hot-potato routing)。此外,当某个(或某些)节点失效时,消息块应能绕过失效节点,继续朝目的地进发。动态路由选择所依据的正是Baran提出的上述理念。

Larry Roberts于1967年得知了Paul Baran的研究成果,并于次年与其会面。最终,Paul Baran以顾问的身份间接参与了ARPANET项目。

得知Paul Baran的研究成果的同时,Larry Roberts还获悉了Donald Davies所做出的研究。Donald Davies是位于伦敦的英国国家物理实验所(National Physical Laboratory,NPL)的物理学家。在对Baran的研究成果一无所知的情况下,此人也提出了类似的以动态方式“路由”分片消息的概念,只是还达不到Baran提出的构建冗余的分布式网络的水平。然而,Davies对研究军用的命令及控制系统并不感兴趣,而是志在研发出一种新形式的公众通信方式。他把在网络中“路由”经过分片的消息的行为,与邮政系统中递送包裹(package)的行为等同视之。于是,他把“经过分片的消息”称为“数据包(packet)”,而非 Baran 提出的称谓——“消息块”。同理,在网络中“路由”数据包的行为,则被他称为“数据包的交换(packet switching)”。

当Davies意识到不同类型的计算机可能都会“自说自话”,以至于相互之间很难直接“沟通”时,便又提出了另外一项重要提议。Davies建议在主机系统和网络之间部署一种小型专用“接口计算机”,并同时让这种遍布整个网络的接口计算机说“通用语言”。

Larry Roberts向各主机站点的科研人员提出ARPANET这一概念时,可以说是叫好声一片,但实施起来却有点不太现实。那时,计算机的资源异常珍贵,几乎没有人愿意再拿出分时计算机的部分资源,来“路由”或处理数据包。Wesley Clark,一名圣路易斯华盛顿大学的工程师,在20世纪50年代中期就已经提出过在主机和网络之间部署那种“小型计算机”的建议了,而与此同时,J.C.R.Licklider在MIT才有了第一次的计算机初体验。这种“小型计算机”在网络中行使“动态路由选择”之职。当时,Clark并不知道Donald Davies也有与其近乎一致的念头。

Roberts采纳了Davies的建议,并把那种“小型计算机”命名为接口消息处理机(Interface Message Processor,IMP)。

Roberts发布了研发IMP的提议请求(Request For Proposal),位于马萨诸塞州剑桥的BBN公司接下了这单生意。早些时候,Licklider也曾在该公司担任过副总裁(VP)一职。BBN公司的第一台计算机正是由Licklider负责采购,自那以后,该公司就从一家声学工程咨询公司转型成了世界领先的计算机研发公司。

BBN 公司 IMP 项目的负责人是 Frank Heart,他选择在一种强化版的 Honeywell DDP-516微型机上研发IMP[8]。尽管DDP-516在构建时遵循了军用标准,足已适应海、陆战场的部署环境,但令Heart忧心忡忡的却并非来自敌方的攻击,而是一群本科毕业生们的觊觎之心。秉持打造高度可靠网络系统的设计理念,IMP 的开发者指望强化版的 516足够皮实,能抗得住修修补补的折腾。

1969年10月,“新鲜出炉”的头两台IMP分别在UCLA和斯坦福研究院(Stanford Research Institute,SRI)“上线运行”,然后又各自通过一条速率为50kbit/s的链路,连接了那两处站点的大型主机,并相互“交换”了历史上第一个数据包。同年12月初,加州大学圣塔芭芭拉分校和犹他大学的另外两个主机站点也相继连接进网络。次年年初,一条用来连接剑桥BBN公司和UCLA的50kbit/s的国际长途链路也在各网络间开通。到了1971年4月,该网络已扩大至由以下15个站点网络组成:

1.UCLA

2.SRI

3.UCSB

4.University of Utah

5.BBN

6.MIT

7.RAND Corporation

8.System Development Corporation

9.Harvard University

10.MIT Lincoln Labs

11.Stanford University

12.University of Illinois at Urbana

13.Case Western Reserve University

14.Carnegie Mellon University

15.NASA Ames Research Center

就这样,ARPANET不但成功搭建,投入运行,其规模还保持了稳步增长态势[9]

ARPANET的首次公开展示,是在1972年10月华盛顿希尔顿酒店召开的计算机通信国际会展(International Conference on Computer Communication,ICCC)上。为了举办这次活动,Robert Kahn花了一年多时间来准备。作为BBN IMP项目的研发人员之一,Robert Kahn参与的工作包括:IMP到主机协议的开发、ARPANET的架构以及对ARPANET稳定性的改进。在那次展示中,大约有40台不同品牌及型号的终端都连接到了一台终端接口处理机(TIP)上,而那台TIP又通过两条速率为50kbit/s的线路,连接到了ARPANET[10]。与会者受邀去操纵运行分布在全美各地的计算机上的各种应用程序。本次会展获得了巨大成功,向计算机和电信行业展示了构建分组交换网络的可行性,更使得许多人坚信电信行业将面临巨大转机。

构建计算机网络的可行性已获充分论证,但还有一个障碍有待克服:在互连头几个ARPANET站点时,每台主机上的指令集都是临时编写的,而且还各不相同。也就是说,主机之间之所以能实现相互通信,其途径只是让每台主机将其通信对象视为“哑终端(dumb terminal)”。

ARPANET与核弹

有关ARPANET的起源,可谓是众说纷纭,但有一种说法流传最广,那就是要用它来对抗核攻击。毫无疑问,Paul Baran在RAND公司的研究课题也是围绕上述目标而展开。但对于Larry Roberts及其手下的科学家来说,核攻击则是虚无缥缈之事。Paul Baran提出的网络幸存理念对ARPANET的架构有着举足轻重的影响,究其直接原因,是由于在那个时代,交换节点以及节点间的链路是出了名的不稳定(有一则典故可为佐证:ARPANET上数据包的首次传输由Charles Kline操刀完成——从加州大学洛城分校发往斯坦福研究中心,这位仁兄在系统崩溃前收到的最后一个字母是“login”中的“g”)。ARPANET之所以需要让数据包交换机/链路具备冗余性,并要求动态路由协议的可靠运行,是为了在链路/节点失效时,能使数据包“绕道而过”,其用意并不是为了对抗核攻击。

1.3 网络工作组

1969年,UCLA被选定为安装IMP的首个站点。这可不是随随便便就拍板的,那儿可是有神级人物Len Kleinrock。当时,Kleinrock已经完成了对事关数据流分析模型的研究工作。与老友Larry Roberts一道在MIT共事时,Kleinrock对Roberts提出的存储转发交换网络理念亦有贡献。在UCLA,Kleinrock筹建了网络测量中心(Network Measurement Center,NMC)。1968年10月,Roberts把分析ARPANET性能的合同授予了NMC。为此,Kleinrock组建了一支由40名研究生组成的团队。

大约在IMP首次上线运行的前一年,来自那4家准备安装IMP的机构的研究生就开始进行会晤了;Steve Crocker代表的机构是NMC。会议的议程是公开的,讨论对象是摆在他们面前的一大堆开发任务。“我们的问题多多,”Crocker回忆道,“IMP与主机如何连接?主机之间如何彼此通信?要用什么样的应用程序来支撑?虽然没人能给出明确的解决方案,但前途似乎一片光明。我们自己设想了各式各样的解决方案——交互式图形、合作处理、自动数据库查询,以及电子邮件——可无人知道应从哪儿迈出第一步[11]。”在讨论之余,他们成立了一个由三个人组成的工作小组:Steve Carr,来自犹他大学;Jeff Rulifson来自SRI;Steve Crocker,来自 UCLA,并任工作组组长。他们三人把工作组命名为网络工作组(Network Working Group,NWG)。由于他们没有BBN公司的正式“编制”,也不受其约束,因此可以自由讨论与计算机网络有关的一切话题。Crocker说:“在我们最早的会晤中,可以畅所欲言,无所不谈,既可以讨论网络未来的样子,也可以谈论网络如何与主机交互。就是这样的集思广益,让我们(或者说是迫使我们)对相关主题展开了深刻而又全面的思考[12]。”

(制定)尚未明确定义的主机到主机协议(host-to-host protocol),是NWG所要探讨的主要话题。从那时起,他们就已经开始酝酿该协议应当如何运作,并同时将共识记录在案了。他们清楚地意识到,他们只不过是一群“学生军”而已;在BBN公司的背后,必须要有一支正规设计团队致力于研发该协议。但BBN公司把主要精力都集中在让IMP可靠地传输数据上了,压根就没有成立正规协议设计团队的想法。

“我记得那时我们诚惶诚恐,害怕会得罪那些‘有正式编制’的协议设计人员。我花了无数个不眠之夜,来修改我们所达成并记录在案的共识,同时还要使措辞尽可能的谦卑”,Crocker 说,“要想达成共识,就必须设定一些基本规则,即人们可以畅所欲言,一切都不用那么‘正规’。”为了强调那些记录在案的共识只是“平等对话的开始,而非独裁式的主张”,Crocker将其命名为“请求注释(Requests For Comments)”。Crocker亲手撰写了RFC1,记录下了当时他们提出的有关主机到主机协议(host-to-host protocol)的想法。

没过多久,管理和编辑RFC的重担就落在了Jon Postel的身上,他是Kleinrock在NMC带过的另一位研究生。Postel一直都担任 RFC的编辑(RFC Editor)一职,直至其1998年撒手人寰。

用来封装和解封装消息的编解码语言(Decode-Encode Language,DEL),是NWG的首批研究成果之一。RFC 5 中,把封装和解封装消息的过程称为封包(packing)和解包(unpacking);把编解码语言称为网络交互语言(Network Interchange Language,NIL),这种语言的用途是:让接收主机“知道”如何解释已发出的信息。整个1969年的春、夏两季,由Crocker牵头的NWG都在努力研发可有效运行的网络协议(working protocol)。“虽然我们觉得计算机间的通信技术发展潜力巨大,但设计出的协议好不好使,则要另当别论……如果我们可使得网络看起来就像是连接到每台主机的磁带机,那么设计起网络协议来那可就方便多啦,但我们都知道事情其实并不那么简单。”离交付第一台IMP的日期越来越近。“那时,我们既有让某些功能先运行起来的压力,也面临着在如何实现协议的高度通用性方面的窘境,而这样的通用性是我们所有人都热切盼望的,我们就这样凭空设计出了第一套协议,其在功能上只包括了Telnet和FTP。实际上,该协议只支持非对称的用户/服务器模型。”同年10月,起远程登录作用的Telnet程序按时交付,并同时为首次连接到SRI做好了准备,在ARPANET上传递的第一个数据包就是由Telnet程序所触发。

但主机到主机协议还尚未实现。“1969年11月,”Crocker写到,“我们与Larry Roberts在犹他州碰头,同时还领教了有生以来第一次飞机改变航向之苦。Larry 使我们清楚地认识到,我们的进展还不够大,还要倍加努力。”

1970年12月,一种名为网络控制协议(Network Control Protocol,NCP)的主机到主机协议准备就绪,可供部署。到了1972年,NCP已经在ARPANET上全方位部署了。起初,在制定这一主机到主机协议的整体架构时,NWG选择使用了分层架构模式。正如Crocker 的吐槽:“我们以主机间协议为基础,还设计了不少高层协议,早期的成果包括Telnet、FTP 以及其他一些零碎的协议。当时要是有先贤大德可以请教就更妙了,没准儿一眼就挑出个7层架构来。”古往今来,智者们所能接受的就是分层式的协议架构。

NWG 还有一位成员,名叫 Vinton Cerf。作为 NCP 的主要设计者之一,他同样是Kleinrock在NMC手把手教出来的嫡传弟子,同时也是Crocker自高中以来的密友。

1.4 互联网的诞生

当别人都在研发IMP时,Bob Kahn却无时无刻不在考虑网络中经常会发生的拥塞现象。他提出了流控算法,根据这套算法(的预测),流量会充斥IMP中的队列,这势必将导致上游 IMP 中的队列“爆满”。这种“级联”式的拥塞最终会使得网络越来越“卡”。但Kahn在BBN的同僚都把精力集中在了工程学方面,不管Kahn如何唠叨,都不肯在他提出的这一“抽象”问题上浪费时间。那些人只是想让网络上线并运行,根本无心对网络性能进行优化。

为此,Kahn于1970年1月进驻NMC,对自己提出的理论展开实验验证。在NMC,他结识了非常肯帮忙的Vint Cerf、Crocker、Postel,以及其他人等。Cerf是这么说的:“Kahn莅临UCLA,对持久有效网络环境(long-haul environment)中的系统运行做出了尝试,我们建立起了富有成效的合作关系。他提出软件所要具备的某些功能性需求,而我则通宵达旦地编程,以满足他的需求,然后我们会一起来验证[13]。”

Kahn可以很轻松地让“新鲜出炉”的ARPANET遭遇各种各样的网络拥塞场景,而那些“场面”与他所预测的结果丝毫不差。此后,他带着那些已获论证的理论回到了剑桥,问题很快得到了解决。尤为重要的是,Kahn与Vint Cerf自此建立起了深厚的友谊和良好的合作关系;不出几年,那些友谊与合作就对计算机网络的发展产生了深远的影响。

Larry Roberts在某段时间内对分组无线网络(packet radio network)很感兴趣,很明显,这与该网络在军事方面的应用密不可分。1972年,Kahn离开BBN公司,到DRAPA任职,Roberts给他分配的工作任务正是“钻研”分组无线网络。于是,Kahn开始研究一种叫做“ALOHANET”的网络。

1969 年,ARPA 资助了夏威夷大学的一个试验性质的分组无线网络项目,该项目由Norman Abramson教授负责。ALOHANET把夏威夷群岛周围的几个站点,与夏威夷大学校区的中央分时计算机连接在了一起。Abramson天马行空般地将他研发出的IMP机型命名为Menehune(一种淘气的夏威夷精灵)。ALOHANET内的用户可籍TIP与ARPANET相连,而TIP则接入Menehune。站在ARPANET的角度来看,这一通过TIP的连接模式只不过是一种终端连接。Kahn则醉心于去研究如何使得ARPANET、ALOHANET或任何一种形式的网络建起起完全对等的关系,让不同网络的主机之间能以“透明”的方式互访。从那时起,DARPA 的 Internet 项目才算正式启动,探究开放式网络架构的序幕也随之拉开[14]

在上述研究开展的同时,Kahn于1972年10月组织了ICCC会议,第一次公开展示了ARPANET。在那次会议上,成立了一个新的工作组——国际网络工作组(International Network Working Group,INWG)。当时,在欧洲,已经启动了好几个分组交换网络项目,INWG的任务就是找到一种方法,把ARPANET与那几种不同类型的网络“连成一气”,从而形成一个国际性的网络。INWG的主席由Vint Cerf担任。

Cerf 和Kahn进行了翻来覆去的沟通,以缓解两人在联网方案上的争执。两位前辈提出的方案是,把ARPANET与分组广播网络及卫星网络(SATNET)互连,因上面提到的每一个网络使用的协议和接口都各不相同,故需根据特定的网络需求进行优化。

1973年初,Cerf提议,应在以上三个网络之间部署路由机(routing computer),来实施互连,他同时把路由机命名为“网关”(gateway)。网关能“理解”其所连接的每个网络的运作机制,以及每个网络内所运行的协议;只要在网关上针对每个直连网络配备了正确的接口,开启了相关运作机制,且能行使数据包的封装和解封装操作,那么数据包就能够在不同的网络间自由流动了。

可是,在联网方案上仍然存在争议。ARPANET是按高可靠性级别来设计的,NCP的运作便依赖于此。就可靠性而言,分组广播链路及卫星链路根本就达不到ARPANET的级别。协议的寻址(addressing)能力,则是另外一个问题。运行NCP的主机只能向下一跳节点寻址,其编址方式类似于现代的MAC地址,不具备大范围内的寻址功能,更别提在全球范围内寻址了。此外,每种网络所能传输的数据包的长度都有上限值,若要在不同类型的网络间传输数据包,就有必要调整数据包的长度。因此,Kahn 着手开发了一种新的主机到主机协议,该协议除能具备全球范围内的寻址能力之外,还兼具丢包恢复、数据包的分片和重组、端到端的校验和计算,以及主机间的流量控制等功能。他请Cerf(此时,Cerf 已晋升为斯坦福大学的教授了)来帮他完成协议的设计,理由再简单不过——Cerf拥有NCP的设计经验。于是,Cerf在斯坦福大学组织了一系列的研讨会(与会者包括学生和访问学者),来参与讨论他本人以及Kahn的构思,或对他们的构思“挑刺”。

1973年9月,在英国苏赛克斯大学INWG的一次会议上,Cerf和Kahn向人们展示了新协议的第一个版本[15]。二位前辈将该协议称为传输控制协议(TCP)。

在接下来的5年里,该协议又经过了4次修改,修改内容包括:新增了三次握手特性;将地址长度从最初提出的24位扩充到了32位。术语“数据报”(datagram)就是在协议修改期间流传开来的。

经过修改的新协议于1977年7月首次公开展示。一辆行使在旧金山Bayshore高速公路上的面包车接入了一个分组无线系统,该系统则通过一台网关连接到了 ARPANET。ARPANET又借助于另一台网关,并分别通过人造卫星链路和陆上线路,连接到了大洋彼岸的挪威和伦敦大学学院(the University College London)。就这样,数据包又从另一条SATNET链路,穿越大西洋,折回了接入ARPANET的南加州大学信息研究院。Cerf是这样描述的:“由于我们所做的一切都是由国防部来买单,因此大家都希望在这次展示中体现出其军事用途来。于是,我们让数据包的往返距离达到了 94000 英里,这远不止ARPANET所能企及的那区区800英里。这次展示大获成功!”

1977年8月,Jon Postel在一篇文章中写道:“我们在internet协议的设计上违背了网络分层原理,以至于铸成大错。说具体点,就是我们试图让 TCP 来行使两项功能:既要让其作为端到端的主机层协议,也要使之成为Internet封包及路由协议(Internet packaging and routing protocol)。然而,以上两项功能应该是以层次化、模块化的方式来实现[16]。”Postel建议把TCP的逐跳(hop-by-hop)功能“转移”进另外一种名叫IP(Internet Protocol)的协议。在同一篇文章中,他提出了如今为人们所熟知的IP包头的概念。随后,Cerf 和Postel撰写了一份“拆分”TCP 功能的规范,这预示着 TCP/IP 的诞生[17]。紧接着,为满足启用尽力服务(best-effort service)时,对IP层直接访问的需求,Postel又定义了用户数据报协议(UDP)协议的规范。

1980年,美国军方将TCP/IP采纳为(军用计算机网络)联网的标准协议,并计划于1983年1月1日在ARPANET内启动从NCP到TCP/IP的“割接”。本次割接完成的非常顺利,这标志着互联网(Internet)的诞生和ARPANET的终结。

互联网是Gore(戈尔)发明的

最近,流传着一个与互联网有关的笑话:有人认为,互联网是美国副总统Gore发明的。故事起源于CNN晚间节目主持人Wolf Blitzer的一次采访。当时,Gore正在角逐民主党的总统候选人提名。Blitzer问Gore,选民为什么应该把票投给他,而不是Bill Bradley。以下文字摘录自Gore的回应:“互连网是我在美国国会任职期间牵头创建的。业已证明,由我牵头制定的一整套措施,不但对我国的经济增长和环境保护起到了重要作用,而且还大大改善了我国的教育体制[18]。”

Gore虽然措辞不当、口齿不清(他在说上面那段话时,使用的句式是“taking the initiative on initiatives”),但其想表达的意思却不难解读,那就是他作为国会议员和参议员,在处理一系列重要事务时,起到了带头人的作用。

记者们很快就抓住了Gore话中的把柄。他们纷纷指出,互联网在1969年就已经发明了(当然,这些人的话也不属实)。那时,Gore根本未在国会任职。Gore的一时失言,到了新闻媒体的嘴里,竟然演变成了:互联网是他发明的。一时间,各种丑角、各路政敌便开始不停地造谣生事,直到人们真的相信是Gore“发明”了互联网。到最后,连Gore都不得不拿这事儿来自我解嘲。

实话实说,Gore自20世纪70年代在相关立法方面的所付出努力,确实对创建人们所喜爱(或憎恨)的互联网的诞生帮助很大。共和党领袖Newt Gingrich是这样说的:“Gore在国会中所付出的卓有成效的努力,确保了人们能够享用到互联网[19]。”

Vint Cerf 和Bob Kahn也针对此事专门撰文:“在我们看来,Gore并不像某些人传言的那样,有意声称是他本人亲自‘发明’了互联网。此外,在我们的印象中,Gore担任参议员时,所提出的某些提案无疑对仍在不断发展中的互联网起到了极其重要的推动作用。实际上,在绝大多数人听说有互联网这回事儿之前,Gore就已经在探讨及推动互联网的发展了[20]。”例举了Gore对互联网的贡献之后,二位前辈总结道:“还没有什么公众人物在宏观上对互联网的发展壮大起到很明显的推动作用……单凭副总统先生早期对高速计算和高速通信技术的价值观,加之他一直以来在互联网对美国人民、对业界以及对其他国家人民具有潜在价值方面的言辞,他就值得人们的尊敬。”

1.5 ARPANET内的路由选择

1983年,在ARPANET内,人们展开了把网络协议从NCP切换成TCP/IP的割接工作。当时,有两拨研究人员同时都在使用ARPANET,分别来自军方和非军方(大学或企业)。就人数而论,第二拨人要多得多,有很多大学生也在学着掌握或使用计算机网络,这反过来又对整个计算机行业产生了影响。此外,还有很多人出于非研究性的目的而使用计算机网络,比如,玩网络游戏。由于使用网络的用户群日渐庞大,美国国防部开始考虑网络的安全性问题,并将军用节点都迁移进了一个隔离的网络,同时把该网络命名为MILNET(军网)。但国防部仍想让军用节点访问到 ARPANET 内的节点,因此在两个网络之间部署了一台网关,来实施互连。这种网络隔离方式实际上只是两个网络分别由专人管控;每个网络内的用户根本就感觉不到有任何差别。把网络协议从NCP替换为TCP/IP之后,才使得MILNET与ARPANET“分家”成为可能。

与此同时,在美国和欧洲,其他各种各样的计算机网络也如雨后春笋般涌现,并开始“互联互通”。其中有一个网络最为重要,并对日后产生了深远影响,这就是由美国国家科学基金会(National Science Foundation,NSF)于1985年开始兴建的NSFNET。兴建该网络的初衷,只是要通过速率为56kbit/s的链路,来互连5个超级计算机(supercomputer)站点。该网络的链路分别于 1988 年和 1990 年被扩容至 T1 和 T3(45Mbit/s)。NSFNET连接了美国各地的大学和公司;更重要的是,整个美国“涌现”出的各种地区性网络都可以自由地接入NSFNET。ARPANET内的低速链路、老掉牙的联网设备(IMP和TIP)以及限制性的访问策略,迫使大多数用户在 20世纪 80年代末“转投”其他网络。于是,DARPA决定让这一20岁高龄的网络“退役”。接入该网络的站点也纷纷连接进了地区性的网络或MILNET,到了1990年,ARPANET便彻底退出了历史舞台。

由上述简短的历史回顾可知,如今在用的网络互连技术几乎都起源自ARPANET。其中包括本书的重点:路由选择技术。20世纪80年代中期,市场上冒出了好几家销售路由器(商业版网关的另一种称谓)厂商,包括:3Com、ACC、Bridge、Cisco、Proteon、Wellfleet等公司。这些厂商的路由器采用的路由算法都传承自ARPANET。有意思的是,BBN 公司的技术人员曾试图说服公司去研发商用路由器,但其市场部门却认为商业用路由器没有任何发展前途。

ARPANET内运行的第一种路由协议由Will Crowther于1969年设计,此人是BBN公司IMP团队的元老级成员。与所有路由协议一样,该路由协议也是基于数学里的图论,采用了Richard Bellman和Lester Randolph Ford算法。Bellman-Ford算法奠定了路由协议里最重要的一类路由协议的基础,多年后,人们将此类路由协议称为距离矢量协议。Crowther设计出的那种路由协议是一种分布式自适应协议(distributed adaptive protocol),其设计理念为:通过调整链路的度量值,让路由器快速适应发生变化的网络特征(自适应);计算通往目的网络的最优路由时,多台路由器要“合力”完成(分布式)。

这种路由协议用延迟(delay)[21]作为度量路由优劣的标准。在每台IMP上,每隔128毫秒,路由协议进程就会统计一次各直连链路(接口)队列里的数据包的个数,并以此作为估算链路延迟的依据。为了不让空闲链路的度量值为0,上述统计结果还会与一个表示最低链路开销值的常量相加[22]。测量接口队列深度(即测量缓存在接口队列中被延迟发送的数据包的个数)的频率越高,运行在每台 IMP 上的路由协议进程就能更快地检测并修改发生变化的链路度量值。就理论而言,在运行这种路由协议的网络中,发往特定目的网络地址的流量应该由所有流量出站方向的链路“平摊”。

运行在IMP上的路由协议进程只要执行了一次延迟统计任务,就会更新一次路由表,然后向邻居IMP通告其路由表。收到路由表之后,邻居IMP会评估(从本机)通往通告(路由表的)IMP的延迟值,将评估结果与所收路由表中的信息相加,用相加的结果去更新本机路由表中通过通告(路由表的)IMP所能访问到的目的网络的信息。邻居 IMP 在更新完本机路由表中的信息之后,会继续向自己的邻居 IMP 通告路由表。当时,上述分布式路由计算的特点,要归因于网络内的 IMP 之间反复的通告路由表,并据此来更新自己的路由表。

这一原始的路由协议在ARPANET运行的头10年里也没出过什么大纰漏。在网络内流量负载很低的情况下,该路由协议做出路由决策的基本方法是:把之前提到的常量与评估而得的延迟值相加。当流量负载攀升到中等程度时,在网络内的个别区域就有可能会出现拥塞状况。在这样的区域内测量出的接口队列深度,会成为让流量改道远离拥塞的某种因素。

随着ARPANET的规模越来越大,加之其内部的流量负载越来越高,这种路由协议所表现出来的问题也就越来越多。某些问题事关测算路由度量值的方式,如下所列。

统计出的缓存在 IMP 接口队列里的数据包的个数是瞬时测量值。在流量很高的网络内,(网络设备接口的)队列深度可谓是瞬息万变,这将会导致路由度量值强烈波动,从而迫使路由表里的路由发生翻动。

统计缓存在 IMP 接口队列里的数据包的个数时,并未考虑不同链路之间可用带宽方面的差异。与低速链路(接口)相比,即便高速链路(接口)所缓存的数据包更多,前者所缓存的数据包的发送延迟也会高于后者。

IMP接口队列里所缓存的数据包的个数(Queuing delay)并不是影响网络链路整体延迟的唯一因素。(网络链路所要转发的)数据包的大小(长度)、IMP处理数据包的时间以及其他因素都会影响到网络链路的延迟。

此外,与距离矢量算法本身有关的各种问题也开始逐渐显现。

随着网络内网络节点数的不断增多,网络节点间交换路由表所产生的网络控制流量也会消耗掉链路的不少可用带宽。

测量链路延迟值和更新路由表的频率,外加测量的结果为队列的“瞬时深度”,不但有可能会限制网络(设备)对拥塞真正出现时的快速反应,而且还会导致网络(设备)在队列深度发生变化时反应“过激”。

分布式路由计算收敛缓慢的天性(也可以说是最大的缺点,即路由传播方式是“好事难出门,坏事传千里[bad news travels fast but good news travels slow]”),会使得距离矢量路由协议易遭受持续性路由环路和错误的影响(第2章会对距离矢量路由协议这一典型的缺陷加以讨论)。

1979年,BBN公司在ARPANET内部署了一种新型路由协议,由John McQuillan、Ira Richer和Eric Rosen共同开发[23]。比之原始的路由协议,这一新型路由协议有三处重大改变。

尽管这一新型路由协议仍旧使用根据延迟值测算出的自适应路由度量值,但在精度方面有所提高,在瞬时程度上则有所下降。

路由信息更新的频率和路由更新数据包的长度都急剧下降,所占用的可用链路带宽也就更低。

路由算法从分布式路由计算(根据邻居IMP通告的路由数据库进行计算),转变为本机路由计算(根据邻居IMP通告的路由度量值进行计算)。

路由度量值的测算方法经过改进之后,大大降低了路由翻动的几率。IMP会把每个数据包的接收时间“烙在”数据包上(接收数据包时,记录接收时间),而不再对缓存在接口队列里数据包的个数进行统计了。在发送数据包的第一位时,IMP还会把发送时间“烙在”数据包上(发送数据包时,记录发送时间)。收到(目的节点)对该数据包的确认消息之后,IMP会用确认消息的接收时间减去数据包的发送时间。然后,IMP再用一个表示数据包所“走”链路的传播延迟的常量(称为偏差[bias]),与另外一个表示数据包传输延迟的变量(其值要视数据包的长度和线路的带宽而定),跟之前提到的接收时间与发送时间之差,进行三者相加[24]。上述计算的结果,肯定会更接近于数据包所“走”链路的实际延迟。IMP会针对其附接的每条链路,每10秒钟取一次测量而得的平均延迟值,这一平均值会成为相应链路的度量值。取链路的平均延迟值,就能够避免取瞬时性测量值时所引发的各种问题。

第二处改变——降低路由更新的频率——是通过设置一个始于64毫秒的阈值来实现的。计算出10秒之内的平均延迟值之后,IMP会将该值与上一次(上一个10秒)的计算结果进行比较。若两值之差不超过阈值,IMP 便不发送路由更新,但阈值会递减 12.8 毫秒,然后用于下一次路由计算。若两值之差超过了阈值,路由更新会照常发出,阈值则会被重置为64毫秒。这一阈值衰减机制,可确保IMP在度量值变化幅度较大时,尽快地将路由更新通告出去,若度量值变化甚微,则可以放慢通告路由更新的速度。若度量值未发生改变,则阈值将会在50秒(64/12.8=5;5×10=50秒)内衰减为0,这会促使IMP通告路由更新。拜这一新路由算法所赐,路由更新的频率以及与此相关的链路带宽消耗,都将会直线下降。

新路由协议路由更新消息中所包含的内容同样非常重要。运行新路由协议的每台IMP不再通告整张路由表,而是只向自己的邻居发送本机链路的度量值;路由更新将传遍整个网络(协议设计者将这一机制称为“泛洪”[flooding]),每台IMP都会在数据库中保存路由更新的一份拷贝。这样的好处有两点:路由更新数据包非常短——均长 22 字节(176位)——这便进一步降低了链路带宽的消耗;由于路由更新消息会迅速泛洪(100毫秒以内)至所有IMP,因此IMP能够更快地“感知”到网络中的发生变化。(在路由更新消息中)设立了序列号、寿命及确认序号(sequence number,age,acknowledgment)等字段,以确保泛洪出去的路由度量值的精确性与可靠性[25]

新路由协议的第三处重大改变是,放弃使用Bellman-Ford算法,采用图论专家Edsger Dijkstra 发明的算法来执行路由计算(这也是本书的重点)。每台 IMP 会根据自己的度量值数据库(数据库的内容要通过泛洪机制来“收集”),执行本机路由计算,以求计算出通往其他所有IMP的最短路径。该机制可基本杜绝路由环路,而路由环路问题已经“折磨”了运行原始路由协议的ARPANET很长时间。McQuillan、Richer和Rosen将他们三人根据 Dijkstra 算法制定出的路由算法,称为最短路径优先(SPF)算法。这就是第一种广泛应用于分组(包)交换网络的链路状态路由协议。

这“第二代”路由协议在ARPANET内整整运行了8年之久,直到再次出现重大故障。该故障要归因于此协议在路由计算方面的缺陷,导致其无法适应网络规模的持续增长。不过,“过错”并不在SPF算法;出问题的只是自适应度量值计算机制。

“第二代”路由协议要根据三个参数,来计算路由的度量值,这三个参数是:(数据包的)排队延迟(其值为收包时间与发包时间相减)、链路传播延迟(这是一个常量[固定值])以及(数据包在链路上的)传输延迟(其值取决于所要发送的数据包的大小和链路速度)。若链路负载很低,排队延迟可忽略不计。若链路负载不高不低,排队延迟不仅会影响到路由度量值的计算,而且还会导致流量在链路之间合理的切换。然而,若链路负载极高,排队延迟势必能“左右”路由度量值的计算。此时,排队延迟可能会引发路由翻动。

以图1.2所示的网络为例。链路A和B分别用来连接网络的东、西二区。东区和西区之间要想交换流量,链路A、B为必经之路。若大部分流量都由链路A承载,则该链路的排队延迟值定会非常高,这一高排队延迟值也将被通告给所有其他节点。其他节点在执行本机SFP计算时,会或多或少的同时进行,因此可能会得出相同的“结论”:链路A已经过载,而链路B负载较轻。于是,所有流量都将“改道”,由链路B来承载,这迫使链路B的延迟大增;在下一次(延迟值)测量周期内,链路B的高延迟情况将会被“散布”出去,造成所有IMP(路由器)让流量继续“改道”,则链路A将承载所有流量。这样一来,链路 A 势必会再次过载,流量又会“改走”链路 B。上述情形将周而复始,流量在链路A、B间的“切换”也会永不停歇。每次发生流量“切换”时,相关链路的负载状况会导致相应路由的度量值发生巨大改变。也就是说,一旦发生了流量“切换”现象,触发流量切换的相关路由度量值就会变得毫无用处(因为流量将会“改走”另一条链路)。

为了解决上述问题,1978年,由BBN公司Atul Khanna、John Zinky和Frederick Serr设计的新路由度量值算法开始在ARPANET内部署[26]。这一新算法仍属于自适应型,沿用了间隔时间为10秒的平均延迟测量方法。当链路负载为中等偏下时,新旧两种路由度量值算法的效果差别不大。只有当链路负载较高时,才能看出新算法在功能性上的改进。在新算法中,路由的度量值不再只是链路延迟值,延迟成为影响度量值的因素之一。此外,还限定了度量值的变化范围。上述举措意在将相同介质网络中其他诸元相等的两条路径间的度量值差距限制在两跳之内。该算法的精髓是启用了一个与链路利用率挂钩的函数,当链路利用率较低时,该算法在运作时似乎只考虑链路延迟,可链路利用率一旦增高,路由的度量值将会根据链路的容量来计算。

虽然 ARPANET所使用的路由度量值算法发生了改变,但只对路由协议的 SPF算法稍作改动,具体的运作方式为:控制流量,令其慢慢“撤离”过载的链路,而不是突然“切换”,这便大大降低了路由频繁“震荡”(流量在不同链路间频繁切换)的可能性。本书不会对这一路由度量值算法做过多纠缠,前文已对自适应路由算法进行了总结:分布式自适应路由协议在运作过程中涉及的东西实在太过复杂。因此,在绝大多数的新型包交换网络中,为追求某些特殊功能(比如,流量工程)而部署的(路由协议的)自适应路由算法都是集中式而非分布式了。如今在用的链路状态路由协议也吸取了早期ARPANET的经验,改用固定的路由度量值,弃用了自适应型路由度量值。

有互联网之父吗

当同胞们把乔治·华盛顿封为美国“国父”时,作者总有那么一点不以为然。作为约翰·亚当斯(John Adams,美国第一任副总统,第二任总统)的忠实拥趸,在作者看来,无论是革命成就,还是后来在外交方面的贡献,约翰·亚当斯都配得上“国父”这一称号(当然,必须承认的是,他并不算是一位好总统)。其他人则可能会把“国父”的头衔安在富兰克林或杰斐逊的头上。把以上几位都视为美国的“开国元勋”,似乎更公道一点。“开国元勋”的意思是:美国的建立靠的是一帮人,而不是靠哪一个人。

互联网的诞生也与此相似。估计大多数人都把Vint Cerf称为“互联网之父”,但是J.C.R.Licklider、Larry Roberts、Len Kleinrock、Bob Kahn、Jon Postel以及其他前辈也配得上“互联网之父”这个头衔。夸大某一个人的贡献,抹杀其余人的功绩,是非常不公平的。互联网并不是只有一个父亲,而是有一大群父亲,外加几个母亲。

在本章陈述的简史中,还有诸多 Internet 奠基人未曾提及,他们中有很多都已离我们而去。为了撰写这部简史,作者查阅了许多参考资料,但最有用的一本参考书是Where Wizards Stay Up Late:The Origins of the Internet,作者为Katie Hafner 和Matthew Lyon[27]。要是读者想知道更多与互联网诞生有关的内容,以及有哪些人为此立下过汗马功劳,作者强烈推荐上面这本兼知识性与趣味性于一体的书籍。

1.6 欧洲的发展

网络工作组(Network Working Group,NWG)为当今与Internet和TCP/IP相关的大多数协议和机制设定了一个基调。一开始,该工作组的成员只是ARPANET头4个站点的一群毕业生和工作人员,他们生怕自己“卑微”的地位,加之在提出协议解决方案时的鲁莽,会得罪那些“有编制”的协议设计人员。好在Internet协议的开发一直都很开放,不但是自下而上来推动,而且还允许任何人参加。RFC就是记录他们工作成果的文档。

“刚开始写RFC的时候,”Vint Cerf写道,“他们还在使用19世纪的沟通方式——以公开交换信件的方式,来讨论各种(运行于ARPANET内的)协议的设计方案的优缺点[28]。”

NWG不断发展壮大,到了1986年,便更名为Internet工程任务组(Internet Engineering Task Force,IETF)。日积月累,IETF已发展成为实际制定IP及相关协议标准的机构。但即便如此,IETF 也从未有过任何章程;它仍然是一个松散的机构,由一群立志创造并改进Internet及网络协议的有志之士构成。如今,设备供应商虽然在网络协议开发方面占主导作用,但同样需要参加IETF成立的工作组,定期会晤,介绍自己的工作进展,让其他人审议和批评。

但是IETF的这种特质也并非每个人都能接受。讲究“行政级别”的政府(能越级沟通的政府也不是没有,只是不多而已)更愿意让也能体现出“层级”观念的官方机构来制定标准。IETF跟这些官僚机构没有半点关系,而国际标准化组织(International Organization for Standardization,ISO)则不然。ISO成立于1946年,总部设在日内瓦,是由两个早期的标准化机构合并而成。该组织的宗旨是,希望通过制定工业标准,来加强国际间制造业的交流,促进贸易的发展,其所制定的标准涉及各行各业,包括:农业、建筑、医药以及电子行业。螺纹、信用卡、劳保用品、机场和公路标识甚至连洗手间的门都有ISO标准[29]

20世纪70年代,实验性的分组交换网络不单是在美国,在欧洲也如雨后春笋般的涌现。多国政府都开始认识到为其制定标准的必要性,但却希望由一个更为官方的机构来出面制定,压根就没考虑IETF。1977年,英国标准协会(British Standards Institute)提议,应由ISO出面,为通信基础设施体系结构制定标准。于是,ISO在Technical Committee(专业标准化技术委员会)97下设立了Subcommittee (附属委员会)16;1978年,Subcommittee 16提出,需要建立一种参考模型,名叫开放系统互连(Open Systems Interconnection,OSI)模型[30]。负责制定 OSI 参考模型发展提议的是 ISO 的美国代表——美国国家标准委员会(American National Standards Institute,ANSI)。

大约与此同时,Mike Canepa和Charlie Bachman在Honeywell信息系统公司开始制定分布式数据库的体系结构。借鉴了 IBM 公司研发的系统网络架构(Systems Network Architecture)的7层模型经验,Honeywell团队于1978年提出了互连计算机的7层架构,并取名为Honeywell分布式系统架构(Honeywell Distributed Systems Architecture,HDSA)。1978年3月,ANSI在休斯顿召开会议考虑OSI模型的提议时,Canepa 和Bachman都已经提出了HDSA。最后,ANSI采纳了他们的模型,这就是当今著名的OSI 7层参考模型的来历。

之后的工作就是要开发出与 OSI 参考模型“配套”的协议。欧洲各国政府及欧州委员会也都把指望寄托在了ISO而不是IETF身上;在美国,虽然军方已经采用了TCP/IP,但商务部下辖的各非军方部门都站在了ISO协议的一边。于是,当1988年ISO终于推出了一套尚未经受过实战考验的协议时,美国政府就迫不及待地接受了OSI协议,根本无视已在现有网络中运行了5年的TCP/IP,而当时OSI协议则连个像样的实现都没有[31]

有了各国政府的大力扶持,OSI协议取代TCP/IP似乎是大势所趋。20世纪80年代和90年代初期,OSI社团只是把TCP/IP视为“学术实验”。然而,最终修成正果成为Internet标准的却是TCP/IP,OSI协议“中道崩殂”。

TCP/IP的“风靡”有部分功劳要记在大受欢迎的UNIX操作系统身上——早在1981年,某些版本的UNIX就开始支持TCP/IP了。但人们接受TCP/IP的最大原因则与IETF和ISO的处事原则有关。IETF关心的是能不能解决实际问题,而ISO总是在尝试开发与预定义的参考模型完全“配套”的协议。IETF 能够迅速发展壮大,要得益于其宗旨:相信共识和可运行的代码(rough consensus and running code),即实现优先,制定标准其次,在制定标准时再去芜存菁(implementing first and then standardizing what worked and abandoning what didn’t);而ISO下属的各个委员会则总在那儿慢吞吞地制定着标准,根本不考虑如何去实现。当时,甚至连按说是 OSI 协议大本营的欧洲各所大学也受不了 ISO拖沓的办事效率,逐渐开始使用TCP/IP了。

然而,有一种脱胎于OSI协议的路由协议仍就对当今Internet的平稳运行起到至关重要的作用,该协议是IS-IS。

1.7 独立且平等

与TCP/IP相比,OSI协议对各国政府、电信运营商以及许多其他机构的吸引力要更大一点,因为 ISO是一家按流程和规矩办事的组织,而 IETF则不那么“循规蹈矩”。由于上面提到的那些机构代表了很大一部分客户群体,因此那时有许多计算机和网络设备供应商都开始着手开发兼容OSI参考模型的协议族。Novell (NetWare)、Banyan (VINES)、General Motors(通用汽车公司)(MAP 和 TOP)、Apple(苹果公司)(AppleTalk)以及许多其他公司也都急不可耐地吹嘘自家网络OS的架构如何符合OSI参考模型(其实有时候也是“削足适履”)。

但是,只有数据设备公司(Digital Equipment Corporation,DEC)在OSI协议的实现方面取得重大进展,该公司开发出的协议也成为了OSI协议的代名词。DEC公司在20世纪 70年代中期便已经研发出了自己的数字网络架构(Digital Network Architecture,DNA),并先后开发出了4个版本的DECnet软件,作为DNA的实现。该公司把DECnet的版本称为阶段(phase),说准确点,DECnet的1-4版本就是DECnet Phases I-IV。1987年,DEC公司推出了DECnet Phase V,并于1991开始销售支持DECnet Phase V的产品[32]。为了在架构上符合OSI参考模型,最新的第5版DECnet软件在前期1-4版的基础上做了大幅改动。ISO也认可了DEC公司的这一“劳动成果”,因此,我们现在所说的OSI协议族跟DECnet Phase V几乎没有任何区别。

内置于DECnet Phase V的网络路由协议,正是由Radia Perlman、Mike Shand、Dave Oran以及其他前辈在DEC公司开发。ISO自然也“照单全收”,作为其IS-IS路由协议。“之所以把路由CLNP数据包的ISO标准称为IS-IS,”Perlman在一本书中写道,“是因为所有其他称谓(例如,ISO10589 中的这段话“中间系统到中间系统域内路由信息交换协议[Intermediate system to Intermediate system Intra-Domain routing information exchange protocol]与……结合使用”)都很糟糕[33]。”

大约在1987年(即ISO将IS-IS采纳为其标准路由协议的同时),IETF也意识到了需要开发出一种链路状态内部网关协议。在那个时代,NSFNET骨干网和许多地区性的网络在部署路由协议时,只有两种选择:一、配置静态路由;二、在需要使用动态路由协议的地方部署RIP。从网络管理的角度来看,静态路由毫无可扩展性而言;而RIP的诸多缺陷也注定其可扩展性极差,而那些缺陷在ARPANET初期运行Bellman-Ford型路由协议时,早已暴露无疑。凭借着专为ARPANET开发的SPF路由协议,以及在ARPANET内运行此类路由协议的经验,IETF 认为有必要开发出一种具备高可扩展性,适用于大型网络的链路状态IGP。

于是,在IETF内部形成了两派。一派把目光盯在了IS-IS身上,他们认为,在有现成的链路状态路由协议可用的情况下,重新开发一种新协议意义不大。干吗不对IS-IS做一番改进,令其支持TCP/IP呢?另一派则不想让如此重要的协议受控于外部组织,何况这个组织还是官场味十足的 ISO。在他们看来,IETF 的行事风格不但已得到了证明,而且人人都觉得很爽,那为何不开发出一种开放的、非私有的 ARPANET 版 SPF 协议——OSPF协议呢?这一开放的SPF协议与TCP/IP的融合度也一定会更好。ISO对TCP/IP不屑一顾的态度,使得这一派打心眼里憎恨ISO;他们不接受IS-IS,只是因为该协议是ISO的标准。

IETF 也没打算让两派决个高下,而是采取了一种妥协的做法,同时接受了“改造”IS-IS以及“自造”OSPF的建议,并把两种协议作为平等而又独立的协议来对待。就这样,IETF分别成立了IS-IS和OSPF工作组。

IS-IS工作组于1990年完成了对IS-IS的改造,令其能够支持TCP/IP,这一经过改造的IS-IS版本被命名为“集成(Integrated)”或“双(Dual)”IS-IS。IS-IS针对IP的扩展功能发表于RFC 1195,作者是Ross Callon,一名DEC公司的工程师,此前他曾效力过BBN公司[34]

OSPF工作组于1989年10月推出了首版OSPF。然而,此版OSPF(OSPFv1)暴露出了几处操作层面的问题,而且某些地方还无法优化,因此从未得到正式部署。工作组对其进行了改进,于1991年7月推出了OSPFv2,并发表于RFC 1147,作者是John Moy[35]。Moy 当时效力于 Proteon 公司,这是一家早期的路由器厂商。他与 Callon 一样,同为前BBN公司的工程师。

1990年,OSPF在几个地区性网络内得到了成功部署。1991年10月,在INTEROP内部署也大获成功。Moy写道:“要想搞一次华而不实的路由协议示范操作非常困难。当路由协议运行正常时,一般人根本就不知道它的存在[36]。”

在整个开发过程中,两个工作组相互取长补短。比如,OSPF和IS-IS共有的在广播网络内选举指定路由器的概念,是最先用于IS-IS的。两个工作组还同时吸取了ARPANET内运行SPF路由协议的教训。比方说,1980年10月27日发生的ARPANET全网瘫痪(详情请见RFC 789),很大程度上要归咎于协议报文字段中序列号的循环取值方式。于是,IS-IS 和 OSPF 不约而同地采用了序列号的线性取值方式(详见第 2 章)。两个工作组都同时认识到了自适应性路由度量值的复杂性,于是便规定了可配置的非自适应型路由度量值。

20世纪90年代中期,Cisco公司正逐步向具有统治性地位的Internet骨干和区域性网络路由器销售商迈进。Cisco公司于1991年开始让路由器同时支持OSPF和OSI版本的IS-IS;又过了几年,该公司又发布了支持IP的集成IS-IS的实现。对IS-IS影响最深的事件发生在1994年,那一年,Cisco路由器开始支持NLSP,这也使得IS-IS在世界各地众多ISP的网络中得到了部署。

几年之前,Novell公司也开始为其NetWare网络操作系统开发链路状态路由协议。在Neil Castagnoli的指导下[37],Novell公司发布了自己的NetWare链路服务协议(NetWare Link Services Protocol,NLSP)。NLSP基本上照搬了IS-IS,只是可以路由Novell IPX数据包而已。(NLSP发布后不久,Radia Perlman便火速加盟了Novell公司,从而书写了一段借IS-IS的东风创造NLSP的神话。)

开发出NLSP实现之后,Cisco公司决定重写IS-IS代码,以求尽可能地将NLSP和IS-IS这两种非常类似的协议,以单协议(IS-IS)的方式融合进IOS。该项目由Dave Katz负责,Cisco最终夙愿成真,得到了稳定而又健壮的IS-IS实现。那时,Cisco的OSPF实现还欠精致,服务提供商对此很不满意。在受到当时 OSI 协议狂躁症的刺激之后,许多ISP都把IGP改成了IS-IS,并自此成为该协议的忠实拥趸,时至今日仍痴心不改。如今,Cisco公司的OSPF代码早已变得“稳如磐石”,但1994~1996年间OSPF给那些ISP留下的不良印象,让他们至今都认为IS-IS比OSPF可靠得多。

1.8 总结

20世纪70年代ARPANET的运行经验,已经印证了距离矢量路由协议(至少是基于Bellman-Ford算法的距离矢量协议)不能满足大型网络可扩展性的需求。目前,OSPF和IS-IS是仅有的两种开放式IP路由协议,两者的稳定性和可扩展性已在大型网络中得到了充分证明。事实上,对任何网络设备厂商而言,只要想做运营商或Internet服务提供商的生意,就必须能够证明其(设备软件中的)OSPF和IS-IS实现能达到运营商级别的要求。

知道了IS-IS和OSPF的起源之后,本书其余内容将深究这两种路由协议,并会对两者细加比较。此外,作者希望读者不但能藉此更为深入全面地了解 IS-IS 和 OSPF,而且还能在为自己的网络甄选路由协议时,做出明智的选择。

[1].Licklider对家用电脑、图形用户界面、点击式输入设备,以及现代化计算机的许多方面都早有预言,其研究成果也使他成为人工智能之父。

[2].J.C.R.Licklider,“Man-Computer Symbiosis”,IRE Transactions of Human Factors in Electronics,Volume HFE-1,1960年3月;“The Computer as a Communication Device”,Science and Technology,1968年4月。上述两篇论文的重印版本,会同Bob Taylor所撰写的一份对J.C.R.Licklider的简介,由DEC公司系统研究中心于1990年结集出版,命名为“怀念J.C.R.Licklider(1915-1990)”,该书的电子版可由如下网址获得:gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-061.pdf。

[3].1972年ARPA被莫名其妙地更名为国防高级研究项目计划署(Defense Advanced Research Projects Agency,DARPA)。

[4].Vannevar Bush,“As We Might Think”,The Atalantic Monthly,1945年7月。

[5].该项目由Tom Marill提议,此人同样是一位心理学家,他研究计算机的方法自成一家。Marill创建了用来在计算机之间交换消息的规程,同时也是把这种规程称为“协议”的第一人。

[6].Leonard Kleinrock,Communication Nets:Stochastic Message Flow and Design,McGraw-Hill,1914年。

[7].Baran后来又参与了StrataCom公司发起的数据包语音技术的开发,该技术后来发展为ATM技术。

[8].当时的微型机(Minicomputer)之所以用“微型(mini)”来命名,是相对于“大型”机(mainframe)而言。Honeywell 516跟电冰箱差不多大,重约1000磅,价值在10万美元左右。

[9].在www.cybergeography.org/atlas/historical.html上,可以找到伴随着ARPANET一起“成长”的联网示意图,以及由Larry Roberts和其他前辈们手工绘制的某些草图。

[10].一年以前,BBN就已经研发出了可以互连多个站点(指无本地主机的站点)的TIP。IMP只配备了4个主机接口,没有终端接口,因此,TIP就是配备了终端接口(最多能连接64台终端)的IMP。

[11].摘自Stephen D.Crocker所著《The origins of RFCs(RFC之由来)》,此文后收入RFC 1000,“The Reguest for Comments Reference Guide”,Joyle Reynolds和Jon Postel,1987年8月。

[12].摘自Steve Crocker所著《The First Pebble:Publication of RFC 1(投石问路:RFC 1的发布)》,此文后收入由RFC编辑和他人合著的RFC 2555,“30 Years of RFCs(RFC 30年)”,1999年4月。

[13].摘自The Online User’s Encyclopedia(Addison-Wesley公司 1993年出版)中的“How the Internet Came to Be”一文(由Vint Certf 口述,Bernard Aboba记录)。

[14].Steve Crocker把Abramson教授的研究成果透露给了Bob Metcalfe。ALOHANET 中与广播介质上的随机访问有关的规程,特别是当碰撞发生时,重传数据包的机制,引起了Metcalfe的高度关注。随后,Metcalfe和David Boggs便借此机制发明出了以太网。

[15].Vinton G.Cerf和Robert E.Kahn,“A Protocol for Packet Network Intercommunication”,IEEE Transactions on Commnnications,Volume COM-22,Number 5,627~641页,1974年5月。

[16].Jon Postel,“Comments on Internet Protocol and TCP”,IEN #2,1977年8月。

[17].某些早期文档把TCP/IP称为IP/TCP。

[18].副总统戈尔参加CNN“Late edition”节目的受访文字稿。www.cnn.com/ALLPOLITICS/Stories/1999/03/09/President.2000/transcript/gore,1999年3月9日。

[19].转引自洛杉矶时报上的文章,“Gore Can Mispeak and That’s No Exaggeration”,作者是James Gerstenzang,2000年9月22日。

[20].Robert Kahn 和Vinton Cerf致Declan McCullaugh和Dave Farber的电子邮件“Al Gore and the Internet”。

[21].译者注:此处的“delay”是指,缓存在IMP的各个接口队列里,被延迟发送的数据包的个数。

[22].提一句与路由选择无关的话题,Bellman-Ford算法在图的分枝上可能会出现负值,而Dijkstra算法则不然,这也是前者的优点之一。

[23].John M.McQuillan,Ira Richter以及Eric C.Rosen,“The New Routing Algorithm for the ARPANET”,IEEE Transactions of Communications,Vol COM-28.No.5,711~719页,1980年5月。

[24].与原始的路由协议一样,使用常量是为了杜绝空闲链路的开销值为零的情况出现。

[25].如2.2.2节所述,这种路由协议的序列号计数方式为循环计数。读者可以去读一下Eric C.Rosen在1981年撰写的RFC 789“Vulnerabilities of Network Control Protocols: An Example”,那里面记录了一个有趣的故事,讲述了以二进制表示的序列号因为在设置方面存在轻微的瑕疵,而弄瘫了整个ARPANET。

[26].Atul Khann和John Zinky,“The Revised ARPANET Routing Metric”,ACM SIG COMM研讨会论文集,45~56页,1989年9月。

[27].Katie Hafner和Matthew Lyon,Where Wizards Stay Up Late:The Origins of the Internet,Simon & Schuster,1988年。

[28].摘自Vint Cerf所著《RFCs-The Great Conversation(RFC-思想的盛宴)》,此文收入由RFC编辑和他人合著的RFC 2555《30 Years of RFCs(RFC30年)》,1999年4月。

[29].读者势必知道,国际标准化组织的“简称”ISO,跟其英文全名并不匹配。那是因为“ISO”就是该组织的名称,并非英文简称,这三个字母取自希腊文单词“isos”,意为“平等(equal)”。该组织如此命名的用意是,使其名称不因各国语音的不同而发生变化。在任何国家,“国际标准化组织”都叫“ISO”。

[30].ISO/TC97/SC16,“Provisional Model of Open Systems Architectures”,Doc.N34,1978年3月。

[31].在美国联邦信息处理标准(Federal Information Processing Standard)(FIPS #146)中,载有由美国国家标准与技术研究院(National Institute of Standards and Technology,NIST)制定的美国政府开放系统互连配置概览(Government Open Systems Interconnection Profile,GOSIP)。

[32].James Martin和Joe Leben,DECnet Phase V: An OSI Implementation,Digital Press,1992年。

[33].Radia Perlman,Interconnections:Bridges and Routers,268页,Addison-Wesley,1992年。

[34].Ross Callon,“Use of OSI IS-IS for Routing in TCP/IP and Dual Environments”,RFC 1195,1990年12月。

[35].John Moy,“OSPF Version 2”,RFC 1247,1991年7月。

[36].John Moy,OSPF:Anatomy of an Internet Routing Protocol,Addison-Wesley,1998年。

[37].Hannes Gredler和Walter Goralski,The Complete IS-IS Routing Protocol,第5页,Springer,2005年。

第6章 链路状态数据库同步

有一句话作者此前曾反复提及,现在再说一遍:链路状态路由协议的“精髓”在于,隶属同一区域的每台路由器都会根据存储在一个公共拓扑数据库里的信息,执行本机路由计算。因此,在同一区域内,每台路由器所存储的拓扑数据库的内容必须完全一样。路由器之间相互同步链路状态数据库的目的正是为此。在OSPF或IS-IS网络中,路由器只要上线运行,就必须与邻居路由器进行数据库同步,以确保各自所持数据库的内容完全相同。若路由器刚接入点到点链路,便会与链路对端的邻居路由器互相同步数据库。若路由器刚接入多路访问网络,则会跟DR或DIS进行数据库同步。在执行完最初的数据库同步任务之后,还有必要采取某些措施,让本机数据库与邻机数据库一直保持同步状态。

请注意,除了跟(直连)邻居路由器同步数据库以外,任何一台路由器都不会与区域内的其他(非直连)路由器进行数据库同步。在每一个区域内,邻居路由器之间就是用“薪火相传”的方式,来执行数据库同步任务。这足能让同一区域内的所有路由器都拥有内容相同的数据库了。当然,这一同步数据库的方式还得有一个前提,那就是区域内的任意两台路由器之间都有路径相连。在一个区域内,只要有一台或多台路由器因“路径中断”而被孤立,便不能确保该区域内的所有路由器都拥有内容相同的数据库。人们把这种情况称为区域分割(partitioned area),第7章会对此加以讨论。目前,读者有必要知道,在某特定区域内,确保所有路由器都拥有内容相同的数据库的一些前提条件。这些条件包括:先通过链路来“串连”所有路由器;再配置路由器,令它们彼此之间建立起“连成一气”的OSPF/IS-IS邻接关系。此外,还要确保不能因单点故障(单条物理链路或单个接口故障)而导致区域内的某台(或某些)路由器与所有其他所有路由器分割开来。

6.1 OSPF数据库同步

读至本章,读者想必知道,OSPF协议是一种结构性很强的路由协议。既然读者都清楚OSPF数据库同步的可靠性和精确性是如此重要,那么也就不会对用来管理OSPF数据库同步过程的状态机(名为邻居状态机)的复杂程度感到惊讶了。简而言之,在数据库同步过程中,邻居状态机会驱动(OSPF路由器)采取以下“行动”。

1.当相邻的两台路由器决定彼此建立邻接关系时,会进行分工:一台起“主导”作用,另外一台会进行“配合”,这便是所谓的主(master)/从(slave)路由器机制。主路由器会掌控数据库同步的其余过程(即数据库交换过程)。

2.邻居路由器之间会以互发某种 OSPF 协议数据包的方式,彼此“展示”本机数据库里存储了哪些LSA(即数据库“展示”过程,也有人称其为数据库描述过程)。

3.在数据库“展示”过程中,若一台路由器得知邻居路由器拥有本机所没有的LSA,或得知邻居路由器所持LSA的“版本”新于本机,就会请求邻居路由器发送相关LSA的完整拷贝。

4.邻居路由器之间交换完各自数据库里的LSA,且两者都认为本机数据库与对方相同,则结束数据库同步过程,于是,便建立起了状态为Full的OSPF邻接关系。

本节首先会介绍数据库交换过程中用到的OSPF协议数据包,然后会深入探讨邻居状态机。

6.1.1 数据库同步过程中所使用的OSPF协议数据包

在数据库同步过程中,会用到5种“常规”OSPF协议数据包中的4种:

数据库描述(类型2)数据包;

链路状态请求(类型3)数据包;

链路状态更新(类型4)数据包;

链路状态确认(类型5)数据包。

上一章已经介绍了OSPF路由器之间如何利用链路状态更新数据包,来泛洪“整条”LSA。此外,上一章还提到,为确保LSA泛洪的可靠性,OSPF路由器如何通过包含LSA头部的链路状态确认数据包,来“直接确认”(explicitly acknowledge)收到的LSA。虽然上一章给出过链路状态更新数据包和链路状态确认数据包的格式,但为方便读者参考,图6.1和图6.2再次显示了两者的格式。

与链路状态确认数据包一样,数据库描述(DD)数据包(其格式见图6.3)也只含可完全标识某条LSA或LSA实例的LSA头部。OSPF路由器会以生成DD数据包的方式,向与其建立邻接关系的邻居路由器“展示”本机数据库内包含有哪些LSA。

接口MTU字段,其值指明了生成(DD数据包的)路由器接口所能发送的不分片数据包的最大长度。若(邻居路由器间互连接口的)MTU 值不匹配,则不能建立邻接关系。否则,邻居双方中的一方就有可能会发出对方无法接收的“大型”OSPF协议数据包。

选项字段,与Hello数据包以及LSA中的选项字段相同,都用来通告生成(OSPF协议数据包的)路由器所具备的OSPF可选功能。在本章之前的内容中,已经简要介绍过了该字段,下一节会详细介绍其格式与用途。

一般而言,LS数据库的规模都不会太小,在此情形,OSPF路由器只生成一个数据库描述数据包,可能并不足以把本机LS数据库里的所有LSA都“展现”给邻居路由器。因此,协议设计人员在DD数据包中设立了以下两位,意在“告知”邻居路由器:本数据包是否是“一串”DD数据包中的一个。

I(Init)位,该位置1时,表示本数据包是“一串”DD数据包中的第一个。

 M(More)位,该位置1时,表示本数据包之后还有后续的DD数据包“跟进”。

以下是对I和M位各种取值方式的解释。

若只用单个 DD 数据包便能把本机 LS 数据库里的所有 LSA 都“交代清楚”,则该DD数据包中的I位置1,M位置0。

若要用“一串”DD数据包才能把本机LS数据库里的所有LSA“交代清楚”,则“一串”当中的首个DD数据包的I位和M位要同时置1;“一串”当中的最后一个数据包的I位和M位需同时置0;首尾之间的数据包I位应置0,M位则要置1。

MS(主/从,Master/Slave)位,其值用来表示生成(DD 数据包的)OSPF 路由器在数据库交换过程中是起主导(Master)(MS位置1)作用,还是起配合(Slave) (MS位置0)作用,即标明生成(DD数据包的)OSPF路由器是主(Master)路由器还是从(Slave)路由器。主/从路由器之间的关系将在6.1.5节介绍。

DD序列号字段,当用“一串”DD数据包才能把本机LS数据库里的所有LSA都“交代清楚”时,该字段会跟I、M位结合使用。DD序列号字段的用途也将在6.1.5节介绍。

在数据库交换过程中,若OSPF路由器在收到的DD数据包中发现了未知LSA或已知LSA的最新版本,便会发出链路状态请求数据包(其格式见图6.4),请求邻居路由器把相关LSA的完整拷贝发给自己。可发出单个LS(链路状态)请求数据包,向邻居路由器“请求”多条LSA,倘若所要“请求”的LSA的条数过多,则可以发出多个LS请求数据包。邻居路由器可以把多条“受到请求”的LSA,装载进单个链路状态更新数据包,然后外发。

请注意,LS请求数据包并不包含完整的LSA头部,只是包含了LSA头部中的LS类型、LS ID,以及通告(路由的)路由器字段。也就是说,路由器发出 LS 请求数据包,是要从邻居路由器那儿“实打实”地请求某条(或多条)LSA,而不是某条(或多条)LSA的某个具体实例。收到LS请求数据包的邻居路由器,自然会发出“受到请求”的LSA的最新实例。LS 请求数据包的格式之所以会如此设计,其目的是要把这样一种情形也考虑在内,那就是:在某台路由器从生成DD数据包(向邻居路由器“展示”本机数据库里的LSA),到收到(邻居路由器发出的)LS请求数据包,向其请求某条(或多条)LSA的这段时间内,邻居路由器可能已经收到(自己所要请求的)LSA 的最新实例,并将之安装进本机数据库了。总而言之,只要收到LS请求数据包,OSPF路由器必会发出“受到请求”的LSA的最新拷贝。

6.1.2 选项字段

(某几种)OSPF(协议数据包所携带的)选项字段是一个 8位的标记集合,每一位都代表着生成(该OSPF协议数据包的)路由器所具备的某项OSPF功能。在上一节介绍过数据库描述数据包之后,含选项字段的各种OSPF协议报文(或信息元素)都已在本书中介绍过了,它们是:

Hello数据包;

数据库描述数据包;

LSA头部。

图6.5所示为选项字段的格式。选项字段中有7位都是当前已启用的标记位,最高位在图中被标记为“*”,写作本书之际,还尚未启用。选项字段那7位中的每一位都表示一种与 OSPF 有关的功能,路由器只有在具备了相应的功能之后,才会把(自生成的某些OSPF协议数据包的)选项字段中的相关位置1。否则,便会把选项字段中的相关位置0。

本节会简单介绍选项字段中每一位的用途,以供读者做一般性的了解。本书后文会专辟几章分别介绍选项字段中各标记位所代表的相关功能。在还没有学过这些内容之前,读者在阅读本节对选项字段的介绍时,可能会略感吃力。

O位,表示(生成相关OSPF协议数据包的)路由器是否具备解读不透明(Opaque) LSA的功能,第10章会介绍不透明LSA。如本书第1章所述,有了不透明LSA,就能对OSPF的功能进行扩展,令该协议支持其原本所不能支持的应用,比如,流量工程。O位只会在DD数据包中置1,也只有能解读不透明LSA的路由器才能将该位置1,也就是说,路由器是否支持与O位“挂钩”的OSPF功能,只有在数据库交换过程中才能显现出来。此后,不透明 LSA 将被泛洪给支持不透明功能的路由器(Opaque-capable router)。

DC位,该位置1时,表示(生成相关OSPF协议数据包的)路由器支持按需电路(Demand Circuit)功能,并能够“解读”与该功能有关的“DoNotAge LSA”,这些内容将在第8章讨论。当互连(OSPF路由器的)链路要按流量或时间来计费时,就可以(在OSPF路由器上)开启按需电路功能。此时,可以配置OSPF路由器上的相关接口(比如,ISDN或拨号接口),令这些接口将其所连链路视为按需电路,这样一来,通过按需电路互连的OSPF邻居路由器之间,既不会定期互发Hello数据包,也不会定期刷新LSA,这就避免了按需电路被毫无必要地“接通”,去传递“控制层面”流量,从而起到节省通信成本的目的。能“解读”DoNotAge LSA的路由器,会在自生成的所有LSA中将DC位置1。此类路由器还会通过连接了按需电路的接口,外发DC位置1的Hello和DD数据包。若此类路由器收到了DC位置0的Hello或DD数据包,则表明邻居路由器不支持或未启用按需电路功能,于是便会改发“普通”的Hello数据包,并“正常”执行LSA的刷新机制。若不支持按需电路功能的路由器收到了DC位置1的OSPF协议数据包,则会对DC位置1的情况“视而不见”。

EA位,该位置1时,表示(生成相关OSPF协议数据包的)路由器能解读外部属性LSA(这种LSA的类型字段值为8)。与这种类型的LSA相关联的功能现已过时,且未得到广泛应用。

N/P位,用来支持Not-So-Stubby区域(详见7.3.4节)。在Hello数据包的选项字段内,该位被称为N位,置1时,表示(生成Hello数据包的)路由器支持(连接)Not-So-Stubby 区域。在 Hello 数据包中,若选项字段的 N 位置 1,那么 E位(表示支持类型5 LSA)必须置0。若邻居路由器之间不能对上述N位和E位的设置方式达成一致意见,便会丢弃对方发出的Hello数据包,OSPF邻接关系自然也无从建立。在NSSA LSA头部的选项字段中,该位称为P位,同来“通知”NSSA ABR,令其执行LSA类型7/5间的转换。

MC 位,该位置 1 时,表示(生成相关 OSPF 协议数据包的)路由器支持多播OSPF(MOSPF)功能。MOSPF路由器会在其生成的所有Hello数据包、DD数据包以及LSA的选项字段中将MC位置1。然而,在Hello数据包中,选项字段的MC位只起“通知”作用。在数据库交换过程中,路由器才会真正检查DD数据包中选项字段的 MC 位,以了解邻居路由器是否支持 MOSPF 功能,MOSPF组成员(类型6)LSA只会被泛洪给支持MOSPF功能的路由器。

E位,该位置1时,表示(生成相关OSPF协议数据包的)路由器支持外部路由功能。若路由器在自生成的相关OSPF协议数据包的选项字段中,将E位置0,则表示其不接受外部(类型5)LSA。只要在网络中开辟了stub区域(详见7.3.4节),就一定会有完全“委身”于此类区域的路由器,这些路由器会在自生成的相关OSPF协议数据包的选项字段中,将E位置0。在外部LSA的选项字段中,E位必定置1;在隶属于区域0及非stub区域的路由器生成的DD数据包和LSA的选项字段中,E位也总是置1,但是只起“通知”作用。在Hello数据包的选项字段中,E位的设置情况会影响到OSPF邻接关系的建立。交换于相邻路由器之间的 Hello 数据包中选项字段的 E 位设置不一致——一方置 1,另一方置 0——Hello数据包便会遭到对方的丢弃,两者之间将建立不了OSPF邻接关系。

T位,该位置1时,表示(生成相关OSPF协议数据包的)路由器支持ToS路由功能。该功能现已过时,且未得到广泛应用。

6.1.3 OSPF邻居数据结构

当OSPF路由器通过某接口收到Hello数据包,首次“探索”到邻居路由器时,会针对其创建邻居数据结构。邻居数据结构(也被称为邻居列表)会包含本路由器必须知道的有关邻居路由器的所有信息。其中的某些信息收集自邻居路由器发出的Hello和DD数据包,而另外一些信息则来源于本路由器跟邻居路由器挂钩的内部进程。以下所列为邻居数据结构表中的具体表项。

状态(State),记录了本路由器根据自身的邻居状态机(详见6.1.6节)识别出的邻居路由器的状态。请注意,千万别把此处所说的“状态”跟接口数据结构中的“状态”混为一谈,在接口数据结构中,“状态”字段表示的是 OSPF 接口的状态,以及该接口与邻居路由器(互连)接口之间的关系。

闲置计时器(Inactivity Timer),是一个周期为“RouterDeadInterval”(路由器失效间隔期)的计时器,针对路由器接口所连链路上的邻居路由器而定义。只要收到该邻居路由器发出的 Hello 数据包,闲置计时器就会归零(重置)。该计时器到期将会触发邻居状态机中的某些事件,这些事件会把该邻居路由器的状态改变为“Down”。

主/从关系(Master/Slave),表示主、从路由器的选举结果,详见6.1.5节。在数据库交换过程中,会牵涉到主、从路由器的选举。

DD序列号(DD Sequence Number),表示在数据库交换过程中,(本路由器)当前发送给邻居路由器的DD数据包的序列号字段值。

最新收到的数据库描述数据包(Last Received Database Description Packet),可根据该表项的内容来确定在数据库交换过程中(与邻居路由器交换数据库时),是否从邻居路由器那里收到了重复的DD数据包。该表项会记录下邻居路由器最近发出的DD数据包中的某些字段值,包括:序列号字段值、选项字段值以及I、M、MS位的设置情况。

邻居ID(Neighbor ID),这一项的内容为邻居路由器的RID,取自邻居路由器发出的Hello数据包,在某些情况下(比如,在NBMA或某些虚拟网络环境中),也可以手工指定。

邻居路由器的优先级(Neighbor Priority),这一项的内容取自邻居路由器发出的Hello数据包的路由器优先级字段值,执行DR/BDR选举时会用到。

邻居路由器(接口)的IP地址(Neighbor IP Address),这一项的内容为邻居路由器用来跟本机互连的接口的IP地址,提取自邻居路由器发出的Hello数据包(包头)的源IP地址字段。当本路由器需以单播方式向邻居路由器发出OSPF协议数据包时,会用该地址作为OSPF协议数据包的目的IP地址。若邻居路由器是网络内的 DR,则这一 IP 地址还会成为本路由器针对该网络生成的路由器 LSA的链路ID字段值。

邻居路由器所支持的OSPF可选功能(Neighbor Option),这一项的内容取自邻居路由器发出的 Hello 数据包(的选项字段),以及在数据库交换过程中发出的DD数据包(的选项字段)。

邻居路由器所知道的备份指定路由器(Neighbor’s Designated Router),这一项的内容取自邻居路由器发出的Hello数据包的指定路由器字段值(即邻居路由器所认为的DR的IP地址)。只有在广播或NBMA网络环境中,其内容才有意义。

邻居路由器所知道的备份指定路由器(Neighbor’s Backup Designated Router),这一项的内容取自邻居路由器发出的Hello数据包的备份指定路由器字段值(即邻居路由器所认为的BDR的IP地址)。同理,也只有在广播或NBMA网络环境中,其内容才有意义。

图6.6所示为一张OSPF邻居表的输出示例。显而易见,其中出现了之前介绍过的大多数邻居表表项及内容。

6.1.4 OSPF路由器在数据库交换和泛洪期间用到的LSA列表

除了上一节所描述的内容之外,邻居数据结构还包括3张表格。这3张与LSA有关的表格,都只会在数据库交换或泛洪过程中“填写”。

链路状态发送列表(Link State Transmission List),列在表里的LSA都已泛洪而出,但尚未获得确认。

数据库汇总列表(Database Summary List),开始(与邻居路由器)执行数据库交换任务时,OSPF路由器会将归属本机及邻机所在OSPF区域的所有LSA,都填入此表。包含于此表的所有LSA都是OSPF路由器要通过DD数据包“秀”给邻居路由器“看”的LSA。

链路状态请求列表(Link State Request List),此表所含LSA均获悉于邻居路由器发出的DD数据包,包含的不是本路由器未知的LSA,就是本路由器已知LSA的最新拷贝。随后,本路由器会发出链路状态请求数据包,请求邻居路由器“传送”表中所包含的LSA。收到邻居路由器发出相关LSA的完整拷贝之后(相关LSA是指,本机请求邻机发送的LSA。邻居路由器会通过链路状态更新数据包,来传送本机请求发送的LSA的完整拷贝),本路由器会将收到的LSA从链路状态请求列表中删除。

6.1.5 管理数据库的交换:主(Master)/从(Slave)路由器机制

(邻居路由器之间)相互交换 OSPF 数据库的内容(LSA)时,(数据传送的)可靠性非常重要,但 LSA 的可靠交换并不可能一蹴而就。因此,当两台路由器(拿本机数据库里的 LSA,跟对方通过 DD报文所“展示”的 LSA)进行比对时,其中一台路由器要负责管理 LSA(即 LS 数据库的内容)的交换过程[1]。应当由哪一台路由器来充当“管理者”(主路由器),其实并不重要,只要邻居双方一致同意就成。RID更高的那台路由器会成为主路由器,从路由器则由RID较低的那台路由器充当。

以下所列为主路由器所肩负的责任。

发出首个DD数据包。

递增DD数据包的序列号字段值。从路由器则没有这个“权限”。

确保每次只能有一个DD数据包“在途”(outstanding)。

在必要时重传DD数据包。从路由器则不能重传DD数据包。

现在,作者以两台相邻的路由器RA和RB为例,来讲解主路由器是如何确定的。RA在验证过本机与RB间具备了双向连通性之后,会立刻决定跟RB建立邻接关系。为此,RA会向RB发出一个空DD数据包(不含LSA头部)。RA会向DD数据包的序列号字段中填入一个独一无二的值;RFC 2328的建议是,根据当日时间来赋值,但有些厂商的OSPF实现也会使用某些其他方法,向(DD数据包的)序列号字段中填入一个起始值。在RA发出的这一空DD数据包中,I、M以及MS位都将置1,表示本数据包是“一串”DD数据包当中的第一个,后面还会有别的数据包“跟进”,RA还同时以主路由器自居(MS位置1)。

收到RA发出的空DD数据包后,RB会检查其中的RID字段值。若RA的RID更高,RB便知其为主路由器,反之,则视其为从路由器。接下来,会发生两件事情。

若RB认为本机为从路由器,便会发出包含本机所持LSA的头部的DD数据包进行回应,这便拉开了数据库交换的序幕。在RB发出的DD数据包中,头部的序列号字段值会跟(RA发出的)DD数据包相同;MS位将置0,这表示本路由器为从路由器,RA为主路由器。在RB发出的首个DD数据包的头部中,I位将会置1,M位置1还是置0,则要取决于RB有没有通过本DD数据包,(一次性)向RA“展示”完本机数据库所保存的所有LSA。

若RB认为本机为主路由器,便会(向RA)发出序列号字段值为自定义,且I、M以及MS位都置1的空DD数据包。收到之后,RA会发出序列号字段值由RB所定义,且MS位置0的DD数据包进行确认,表示本机为从路由器。在这一用来行使确认功能的DD数据包中,会包含RA所持LSA的头部,数据库交换过程也随即开始。在这一DD数据包的头部中,I位将会置0,因为这并非RA发出的第一个DD数据包;M位置0还是置1,则要取决于RA有没有通过该DD数据包,(一次性)向RB“展示”完本机数据库所保存的所有LSA。

在验证过与对方具备了双向连通性之后,RA和RB有可能会几乎同时发出空DD数据包,分别声称自己为主路由器。对于这种情况,相邻两台路由器只要一收到对方发出的DD 数据包,就知道谁是“主”,谁是“从”了。此时,会由从路由器来启动数据库的交换过程,具体做法是:发出包含LSA头部的DD数据包,并在其头部的序列号字段中填入邻居路由器所发DD数据包的序列号字段值,且把MS位置0,对邻居路由器发出的空DD数据包进行确认。

6.1.6 节会细述(邻居路由器之间)进行数据库交换的完整过程。目前,读者只要知道在确立了主、从路由器之后,由主路由器负责“管理”数据库交换就够了。由于只有主路由器才能增加 DD 数据包的序列号字段值,因此当主路由器发出序列号字段值为 X 的DD数据包之后,只要从路由器能够收到,就会发出序列号字段值同为X的DD数据包(其中会包含本机所持LSA的头部),以“间接”的方式进行确认。同理,只有收到了从路由器发出的序列号字段值为 X 的 DD 数据包之后,主路由器才能继续发送序列号字段值为X+1的DD数据包。通过上述规则不难发现,(发生在邻居路由器间的)数据库交换行为就是一台路由器“主导”或“主动轮询”(poll),另一台路由器“配合”或“被动响应”的过程,即主路由器轮询,从路由器响应(respond)。

DR必会是主路由器吗

在DR推举过程中,若路由器的优先级全都相同,RID最高的路由器将成为DR。因此,有些读者势必以为,当DROther 与DR进行数据库同步时,DR一定会是主路由器。DR在广播或NBMA网络中所承担的职责可能又进一步巩固了上述推理。但事实上,在DROther与DR进行数据库交换时,却颇有可能发生DROther为主,DR 为从的现象。请牢记,DR 在选定之后,如无意外不会“逊位”。也就是讲,在以太网络中,新上线运行的路由器即便RID高于现有的 DR,也不能自动“取而代之”。若此路由器与DR进行数据库交换,则必担当主路由器之职(此路由器的RID更高),而DR一定会成为从路由器。

6.1.6 OSPF邻居状态机

在介绍过用来支撑(OSPF路由器间)数据库交换的所有必要组件之后,现在是时候了解OSPF路由器的各种状态、导致OSPF路由器的状态发生改变的各种事件,以及状态发生改变时,OSPF 路由器所采取的动作了。OSPF 邻居状态机由一整套状态、事件和动作构成,详情请见RFC 2328的10.8节。

读者需要记住,OSPF路由器会单独针对每一个邻居维护邻接状态信息,这些信息明确了本机与某特定邻居之间目前的关系。在相邻的两台路由器之间(尤其是在建立起状态为Full的邻接关系之前),可能会发生邻接关系状态认知度不统一的情况(比如,甲、乙两台路由器相邻,在甲路由器上,显示其与乙路由器之间为 A 状态;在乙路由器上,显示其与甲路由器之间为B状态)。以下所列为各种OSPF邻接关系状态。

Down(失效)状态,此乃邻居会话的最初状态。把邻居路由器的状态显示为Down,即表明在最近一次路由器失效间隔期(RouterDeadInterval)内,未收到该邻居路由器发出的Hello数据包。OSPF路由器不会向状态为Down的邻居路由器发送Hello数据包,但NBMA网络环境除外。在NBMA网络环境中,(OSPF路由器)会按一定的频率(数据包的发送间隔时间要远高于一般的 Hello 间隔时间[Hello Interval]),(定期)向状态为Down的邻居路由器发送Hello数据包。这一在NBMA网络中向(失效的)邻居路由器发送Hello数据包的间隔时间称为PollInterval(轮询间隔时间),其时长通常为2分钟。

Attempt(尝试)状态,此状态只限于NBMA网络环境。把通过NBMA接口相连的邻居路由器显示为Attempt状态,则表明在本机配置中已手工指明了邻居路由器的 IP 地址,本机会“力争”获得邻居路由器的响应。之所以说“力争获得邻居路由器的响应”,是因为本机在发送 Hello 数据包“联络”邻居路由器时,发包的间隔时间为HelloInterval(Hello间隔时间,一般为30秒),并非之前提及的PollInterval(轮询间隔时间,一般为2分钟)。

Init(初始)状态,把邻居路由器显示为 Init 状态,则表明本机已收到邻居路由器发出的Hello数据包,但在其邻居路由器字段中未发现本机的RID(即无法确定与邻居路由器之间是否具备双向连通性)。本路由器会把处于 Init 状态(或更高级别的状态)的所有邻居路由器的RID,填入自生成的Hello数据包的邻居路由器字段,然后通过相关接口外发。

2-Way(双向通信)状态,把邻居路由器显示为2-Way状态,则表明本机跟邻居路由器之间具备了双向连通性,亦即在邻居路由器发出的Hello数据包的邻居路由器字段中发现了自身的RID。只有处于2-Way或更高级别状态的路由器才有资格参与DR选举。

ExStart(准备交换)状态,把邻居路由器显示为ExStart状态,则表明已经拉开了数据库交换的序幕。在此状态下,邻居路由器会确定“邻里之间”的主/从(Master/Slave)关系,以及用来执行数据库交换的DD数据包的初始序列号(即序列号字段的初始值)。只有把邻居路由器显示为ExStart或更高级别的状态,才能认为本机与邻居路由器建立了邻接关系,不过,在数据库同步进行完之前,还不能说邻接关系建立“齐备”(还未建立起状态为Full的邻接关系)。

Exchange(交换)状态,把邻居路由器显示为 Exchange 状态,则表明本路由器正在向邻居路由器“秀”(展示)自己的LS数据库,“展示”的方法是:向邻居路由器发出DD数据包,其中包含了存储在本机数据库里的所有LSA的头部。与此同时,本路由器还可以发出链路状态请求数据包,请求邻居路由器发送包含在链路请求列表里的LSA(即在链路请求列表里由链路状态类型、链路状态ID和通告[路由]的路由器这三个字段共同标识的 LSA)。当 OSPF 路由器向邻居路由器泛洪LSA时,邻居路由器必须处于Exchange或更高级别的状态。

Loading(加载)状态,把邻居路由器显示为Loading状态,则表明本路由器已向邻居路由器“秀”完了自己的 LS 数据库,但还没有从邻居路由器那里“接收”完本机请求发送的LSA,或邻居路由器还没有“接收”完它请求本机发送的LSA。

Full(齐备)状态,把邻居路由器显示为Full状态,则表明本路由器跟邻居路由器之间的邻接关系状态已建立齐备,这样的邻接关系会同时在(双方发出的)路由器LSA或网络LSA中有所体现。

图6.7所示为两台路由器从彼此发现,到互相同步数据库,再到邻接关系建立齐备时,典型的邻居状态变迁的全过程[2]。图中两台路由器互连接口的 OSPF 网络类型为broadcast。

以下所列为出现在图6.7中的各个步骤。

1.RA在广播网络内上线运行,发出Hello数据包,宣布自己上线运行。在RA发出的Hello数据包中,DR字段值被设置为0.0.0.0,邻居路由器字段为空,表示RA尚未发现任何邻居路由器。

2.RB收到RA发出的Hello数据包后,会针对RA构建一套邻居数据结构。RB会把RA置为Init状态,因为在RA发出的Hello数据包的邻居路由器字段内,未出现RB的RID。RB向RA发出Hello数据包时,会在邻居路由器字段内填入RA的RID(10.0.0.1)。对于本例,由于RB是该广播网络内的DR,因此会把本机用来连接该广播网络的接口的IP地址(10.1.1.2),填入(发送给RA的Hello数据包的)DR字段。

3.当RA收到RB发出的Hello数据包后,也会针对RB构建一套邻居数据结构。由于在此 Hello 数据包的邻居路由器字段中发现了自身的 RID,因此 RA 就知道跟RB之间已经具备了双向连通性。此时,RA可以把RB置为2-way状态。但因RB是(该广播网络内的)DR,故 RA 必须与其进行数据库同步。于是,RA 把 RB置为了ExStart状态,表示本机开启了主/从路由器的选择,并同时用LSA来填充数据库汇总列表(详见6.1.4节),那些LSA都是要“秀”给RB“看”的LSA。RA向RB发出了空DD数据包(不含LSA头部),在其中提出了自己的“建议”——为序列号字段设置了一个初始值,并同时将MS位置1。由于那个空 DD数据包的作用只是“探路”,后面还会有 DD 数据包“跟进”,因此 I、M 位同样都被置1。

4.收到RA发出的空DD数据包后,RB会把RA置为ExStart状态,并同时用某些LSA来填充数据库汇总列表,那些LSA都是要给RA“过目”的LSA。然后,向RA发送空DD数据包。由于RB的RID高于RA,因此RB知道本机应作为主路由器,于是会把这一空DD数据包的MS位置1,并自行为序列号字段设置了一个初始值Y。在该DD数据包内,I、M位同样都被置1,表示这是RB发出的首个DD数据包,后面还会有DD数据包“跟进”。

5.收到 RB 发出的首个(空)DD 数据包后,RA 便知 RB 为主路由器了。随着主/从路由器选举完毕,数据库交换的序幕也随即拉开,因此 RA 会把 RB 置为Exchange状态。RA会向RB发出DD数据包,其序列号字段值为RB(在空DD数据包内)设置的初始值Y;MS位则置0,表示本机为从路由器。该DD数据包中会包含“刊登”在数据库汇总列表里的多个 LSA 的头部,“刊登”在数据库汇总列表里的LSA跟RA所持LS数据库里的LSA相同。对于本例,RA要发多个DD数据包,才能向RB完整地展示本机LS数据库(里的LSA),因此,该DD数据包的M位将会置1,表示后面还有DD数据包会“跟进”;而I位则会置0,因为这并不是RA发给RB的第一个DD数据包了。

6.收到RA发出的(含LSA头部的)DD数据包后,RB会把RA置为Exchange状态。对于 DD 数据包中包含的本机所需要的任何一条 LSA,RB 都会录入进链路状态请求列表(见6.1.4节)。然后,RB向RA发出DD数据包,其中会包含“刊登”在数据库汇总列表里的多个LSA的头部。身为主路由器,RB要负责把该DD数据包的序列号字段值调整为Y+1。跟RA相同,RB也得发出多个DD数据包,方能向RA完整地展示本机LSA数据库(里的LSA),当然,该DD数据包的M位将会置1。此外,RB还会将通过该DD数据包对外“展示”的LSA录入链路状态重传列表,并启动重传计时器。

7.收到了RB发出的DD数据包后,RA会先从数据库汇总列表中,将此前已向RB展示过的LSA清除,那些LSA的头部都包含在此前RA向RB发出的DD数据包内(详见步骤5)。若RB在该DD数据包中“展示”的LSA有自己所需,RA就会把那些LSA录入链路状态请求列表。然后,RA将继续向RB发送DD数据包,其中会包含“刊登”在数据库汇总列表里的“下一批”LSA 的头部。RA 也会把该DD数据包中的序列号字段值设置为Y+1。如此一来,RA也就向RB确认了本机已收到其此前发出的DD数据包,以及包内所包含的LSA的头部。

8.收到了RA发出的序列号字段值为Y+1的DD数据包后,RB会停掉之前启动的重传计时器,该计时器是为之前发出的DD数据包中所要“展示”的LSA而启动。此外,RB还会从链路状态重传列表中清除那些LSA。然后,RB会继续向RA发送新的 DD 数据包,其序列号字段值为 Y+2,其中包含了要“秀”给 RA“看”的下一批LSA(的头部)。通过该DD数据包,RB也“秀”完了“刊登”在数据库汇总列表里的LSA,因此此包的M将置0,表示后面没有DD数据包“跟进”。

9.收到了RB发出的最后一个DD数据包(其M位置0)后,RA知道RB“秀”完了自己的数据库。但由于 RA的链路请求列表里还“刊载”有尚未请求 RB发送的LSA,因此RA会把RB置为Loading状态。然后,RA再发出序列号字段值为Y+2的DD数据包,确认已经收到了RB发出的最后一个DD数据包。在此DD数据包中,包含了RA的数据库汇总列表里的最后一批LSA的头部,所以此包的M位会置0。

10.收到RA发出的最后一个DD数据包后,RB会从链路状态重传列表中,清除已得到RA确认的LSA。此时,在RB的链路请求列表中已无任何LSA,这表示RB已对RA数据库里的所有LSA“一清二楚”,于是,便将RA置为Full状态。但RA 的链路状态请求列表中还“刊载”有 LSA,因此 RA 会发出链路状态请求数据包,请求RB发送相应的LSA。RB会以链路状态更新数据包进行回应,其中包含了RA所要请求的完整的LSA。当RA的链路状态请求列表为空时,则表示其已从RB那里收到了自己需要的所有LSA,于是,会把RB置为Full状态。

由图6.7可知,OSPF路由器只有在收到(邻居路由器发出的)相关OSPF协议数据包后,才会改变邻居路由器的状态。导致OSPF路由器改变邻居路由器状态的事件包括:收到了邻居路由器发出的OSPF协议数据包,或邻居路由器发出的OSPF协议数据包里的内容发生了改变[3]。然而,并不是所有导致 OSPF 路由器改变邻居路由器状态的事件,都与自己收到(邻居路由器发出的)相关OSPF协议数据包有关。

以下所列为会让邻居路由器的状态呈“良性”发展的事件。

HelloReceived(收到Hello数据包)——收到了邻居路由器发出的Hello数据包。

Start(启动)——在Hello间隔时间(Hello Interval)内,应向邻居路由器发送Hello数据包。本事件只对位于NBMA网络中的邻居路由器生效。

2-WayReceived(双向连通性具备)——在邻居路由器发出的Hello 数据包(的邻居路由器字段)中,发现了本机RID,这表示本机与邻机之间具备了双向连通性。

NegotiationDone(完成协商)——完成了主/从路由器的协商。

ExchangeDone(完成交换)——两台路由器都通过DD数据包,把本机数据库里的LSA完全展示给了对方。

BadLSRequest(链路状态请求出错)——收到了(邻居路由器发出的)链路状态请求数据包,但其所请求的 LSA 在本机数据库里没有,这表示在数据库交换过程中发生了错误。

LoadingDone(数据库加载完毕)——数据库交换过程完毕之后,链路状态请求列表也已清空。

AdjOK?(能建立齐备的邻居关系吗?)——这是一个决策点,表示(本路由器在决定)应不应该跟邻居路由器建立或维持邻接关系。

图6.8所示为邻居路由器的状态与事件(是指能使邻居路由器的状态呈“良性”发展的事件)间的关系图。

还有一些事件会使邻居路由器的状态呈“恶性”发展。这些事件大都因错误、故障或计时器到期所致。当邻居路由器处于以下任一状态时,就会发生这些事件。

SeqNumberMismatch(序列号不匹配)——收到了(邻居路由器发出的)DD 数据包,但其序列号字段值跟本机预期的不符(不是 N+1)、I 位设置有误,或选项字段值跟上一次收到DD数据包里的不一样。该事件会导致(本路由器)放弃或重新开始与处于ExStart状态的邻居路由器交换LS数据库。

1-Way(单向连通性)——与邻居路由器之间丧失了双向连通性,其征兆为:在邻居路由器发出的Hello数据包的邻居路由器字段内,未发现本路由器的RID。若邻居路由器处于2-Way或更高级的状态,则(本路由器)会将其置为Init状态。

KillNbr(邻居路由器“失踪”)——与邻居路由器完全失去了“联系”,(本路由器)会将其置为Down状态。

InactivityTimer(计时器闲置)——在最后一次路由器失效间隔时间(RouterDeadInterval)内,未收到邻居路由器发出的Hello数据包,(本路由器)会将其置为Down状态。

LLDown(底层协议状态为Down)——底层协议(lower-level protocol)显示邻居路由器不可达,导致(本路由器)会将其置为Down状态。

6.1.7 OSPF排障方法1:学会解读路由器生成的日志记录及Debug输出信息

OSPF 路由器间的数据库交换过程,并不总是像上一节描述的那般“井然有序”。比方说,(OSPF邻居之间)仍然在交换DD数据包的同时,可能还会互相发送链路状态请求和链路状态更新数据包。此外,(一台路由器)接口状态(的改变)也会对邻居路由器的状态产生影响。不管怎样,只要能弄清在建立起状态为Full的OSPF邻接关系的过程中,邻居路由器之间是如何“互动”的,肯定会对排除OSPF故障有极大帮助。

要是相邻两台OSPF路由器之间建立不了邻接关系,那么应首先从哪儿查起呢?

互连接口的IP地址配置正确吗?

能ping通邻居路由器的互连接口的IP地址吗?

OSPF邻居路由器间互连接口的IP地址都隶属于同一OSPF区域吗?

若启用了OSPF认证功能(详见第9章),两“边”的认证信息配置一致吗?密码或密钥匹配吗?

两“边”的OSPF可选功能配置是否一致?

两“边”的各种OSPF计时器配置是否一致?

OSPF邻居路由器间互连接口的MTU值是否匹配?

要是经过一翻排查,上述所有问题的答案都是“是”,但 OSPF邻接关系仍“死活”建立不了,那就应该去深究邻居路由器间的“互动”过程。也就是说,需要在路由器上通过任何一款可用的 OSPF 排障工具,来记录并“破译”邻居路由器间的“会话”。此类排障工具不但能准确地“告诉”网管人员,故障出在邻接关系建立或数据库同步的哪一步,而且还能帮助定位故障的原因,或至少能让人获得一点“蛛丝马迹”。网管人员可根据这些“蛛丝马迹”,来进一步判断故障的原因。

图6.9所示为由一台Juniper路由器生成的日志文件,其内容包括了各种OSPF事件、协议数据包的收发过程以及邻居状态的变迁。作者对这份日志文件(以及图7.10 中的Debug 输出)做了适当的修订,删去了某些无关信息,比如,记录 Hello 数据包的收发情况的信息。

这份日志文件记录了(本路由器)与邻居路由器建立状态为Full的OSPF邻接关系的整个过程。乍一看,这份日志文件有好几页纸,让人望而生畏。但只要读者了解了与接口和邻居有关的各种状态,弄清了导致这些状态发生改变的各种事件,同时熟知构建邻接关系所涉及的协议数据包与各种表格(比如,邻居列表、链路状态发送列表、数据库汇总列表等),读懂这份日志文件却也不难。因此,作者并没有逐句解读这份日志文件,而是提出了一些问题,让读者自己寻找答案。以下所列为相关提示信息。

本路由器的RID为192.168.254.6。

本路由器的接口IP地址为192.168.7.1。

本路由器的物理接口为fe-4/0/0.0。

邻居路由器的RID为192.168.254.8。

邻居路由器的接口IP地址为192.168.7.2。

请读者在阅读日志文件的过程中,对时间戳多加注意,此外,请千万不要把接口状态的改变(interface state change)和邻居状态的改变(neighbor state change)混为一谈。以下为作者提出的要求或问题。

首先,应根据状态的“变迁”,把这份日志文件分为几个部分来解读。

从开始发现邻居路由器192.168.254.8,到与其建立起状态为Full的邻接关系,一共经历了多长时间?

请注意,日志文件显示的邻居状态的变化过程是从Init状态到2-Way状态,再到ExStart状态,而非上一节示例中所描述的从Init状态直接过渡到ExStart状态。请仔细阅读与上述邻居状态的改变有关的日志记录,看看能否找到“理论依据”。(提示:请留意与接口状态的改变有关的日志记录。)

数据库交换过程实际要耗时多久?

进行数据库同步时,网络内已经存在DR和BDR了吗?

每一家厂商的路由器都有自己的一套排障信息生成(提供)方法,其基本原理全都相通,只是输出格式有所不同。只要能够理解底层协议及其运作机制,就应能不费吹灰之力地读懂任何一家厂商的路由器生成的路由协议相关的日志信息。

有一台Cisco路由器,与生成图6.9所示日志记录的那台Juniper路由器相邻,这台Cisco路由器接入该广播网络的物理接口为E0。图6.10所示为该Cisco路由器生成的与OSPF邻接关系的建立、(邻接关系建立过程中发生的)事件以及协议数据包的收发有关的Debug输出。这份Debug输出所覆盖的时间范围跟图6.9所示的日志文件大致相同。

跟之前一样,也应根据状态的“变迁”,把这份Debug输出分为几个部分来解读。

从这份Debug输出中找出与图6.9所示的日志文件中相匹配的事件。

两台路由器的时钟并未同步,可能会有1~2秒的误差。对于两份输出中相匹配的事件,在发生的时间周期上也匹配吗?

根据图6.9和图6.10所提供的信息,像图6.7那样试着画一张图,来描绘出两台路由器之间协议数据包的交换情况,以及邻居状态的变迁过程。

6.1.8 OSPF排障方法2:学会比较(不同路由器的)LS数据库

在新型OSPF或IS-IS网络中,导致路由选择故障(数据包不能正确转发)的原因一般都非常常见,不是链路故障,就是路由器配置有误。通常,只要仔细观察路由器的路由信息表和转发信息表,便不难发现故障的根源。因某个区域内(OSPF 路由器间的)LS数据库不一致,而造成的路由选择故障非常罕见。说其罕见,是因为倘若一对OSPF邻居路由器在同步过数据库之后,LS数据库还不能保持一致,将会导致邻接关系的“破裂”。此外,区域内的路由器在做出路由决策时,也会将邻接关系建立出现问题的这对路由器之间的路径(链路)排除在外。

然而,(区域内OSPF路由器间)LS数据库不同步的现象却绝对有可能发生。这多半要拜赐于糟糕的OSPF实现,或包含OSPF实现的OS出现了 bug。本节会展示如何比较(不同路由器的)LS数据库,以帮助读者应对某些极端情况。所谓极端情况是指:明知网络中发生了路由选择故障,但不管怎么查,都查不出故障原因。

首先,应比较(不同路由器的)LS 数据库汇总信息,以验证存储在每台路由器的数据库里的 LSA 的类型和数量是否匹配。跟上一节所举示例相同,由不同厂商的路由器生成的LS数据库汇总信息的输出(格式)虽然各不相同,但所反映出的内容却大体相同。图6.11和图6.12分别显示了由Juniper和Cisco路由器(即上一节用来举例的那两台路由器)生成的LS数据库汇总信息。经过比较,可以发现两台路由器在区域0的LS数据库里存储的LSA至少在条数上相同:

4条路由器LSA;

4条网络LSA;

10条网络汇总LSA;

1条ASBR汇总LSA;

2条外部LSA(在Cisco路由器生成的LS数据库汇总信息里,这2条外部LSA出现在“Process 1 database summary”下的“Type-5 Ext”一栏)。

由于那台Cisco路由器(见图6.12)担任ABR一职,固其还持有区域20的LS数据库。但区域 20 的 LS 数据库的信息跟本节所要讨论的内容无关,理由是那两台路由器的互连接口都隶属于区域0。

虽然那两台路由器的LS数据库所保存的LSA的条数匹配,但会不会发生一条或多条LSA 的实例不一致的现象呢?要想对此加以验证,就得先把那两个 LS 数据库里的所有LSA的校验和分别相加,然后再进行比较。只要那两个数据库里的LSA实例相同,校验和的相加结果也必定相等。否则,就得到两个数据库中分别比较每条 LSA 的校验和,以发现不一致的LSA的实例。

图6.13和图6.14分别显示了Juniper路由器和Cisco路由器生成的LSA头部的输出。作者分别把两个数据库里的所有LSA(只限于区域0,不含外部LSA)的校验和累加,得到的结果都是0xB4C0D。

所有路由器LSA的校验和相加:0x2938A。

所有网络LSA的校验和相加:0x24718。

所有网络汇总LSA的校验和相加:0x5F5AE。

所有ASBR汇总LSA的校验和相加:0x7BBD。

Juniper 路由器和 Cisco 路由器的两条外部 LSA 的校验和之和分别为0x12406和0x12804。当然,对于本例,逐一比对两个数据库里的那两条外部LSA的校验和,要比比较两条外部 LSA 的校验和之和简单得多。不过,要是数据库的规模一大,哪种比较方法更加简单,那就很难说了。让人头痛的是,对于大型网络,路由器控制台显示出的LS数据库的输出,肯定会比图6.11和图6.12长很多,无论使用哪种比较方法都既容易犯错,又枯燥无味。更悲催的是,要是读者在捕获两台路由器的LS数据库输出的间隔期,网络中有路由器刷新了自己的数据库,那么即便那两台路由器的LS数据库的内容一致,相比较的结果也肯定不匹配。

幸运的是,解决方案倒不是没有。无论读者管理什么样的网络,只要网络规模一大,多半都会部署基于SNMP的网管软件。利用以下所列OSPF MIB,就能(通过网管软件)自动采集到LSA的校验和之和,可让网管人员免遭枯燥无味的十六进制数加法计算之苦。

ospfAreaLsaCksumSum 能用来获取一个区域内所有 LSA 的校验和之和(外部LSA除外)。

ospfExternLsaCksumSum 能用来获取外部(类型5)LSA的校验和之和。

然而,(两台路由器数据库里的)LSA的校验和之和不匹配,只是表明存在数据库同步问题。单凭这些信息,既无法定位导致问题的原因,也肯定搞不清具体是哪条LSA不匹配。退一步来说,一般的网管人员能判断出网络存在OSPF数据库不同步问题,水平也算不俗。在判断出网络存在类似问题之后,网管人员可尝试先手工拆除,再重建邻接关系,让相关OSPF邻居路由器之间重新同步数据库。若症状还未消失,那就赶紧致电设备厂商的技术支持团队,需要由他们来深入分析,并判断OSPF软硬件实现方面是否存在问题。

6.2 IS-IS数据库同步

OSPF路由器要想启动数据库交换过程,不但需要其邻居路由器明确同意,还得依靠状态机来进行严格地管理;而IS-IS路由器交换数据库的过程要简单很多,邻居路由器之间会定期把自己的整个数据库“秀”给对方看[4]

通过点到点链路互连的IS-IS路由器之间会定期互发CSNP,向对方“展示”本机LS数据库里的内容。若一台路由器在收到的CSNP中发现了本机未知的LSP,或本机已知的LSP的最新拷贝,便会发出PSNP,请求邻居路由器发送相关LSP的拷贝。同理,该路由器若在收到的CSNP中发现,邻居路由器缺少本机数据库中的某条LSP,或本机数据库里的某条LSP的拷贝要比邻居路由器的新,便会“主动”把相关LSP的拷贝发送给邻居路由器。

在广播网络内,DIS会定期以多播方式发送CSNP;跟点到点链路互连的IS-IS路由器一样,此类网络内的其他路由器也会拿DIS发出的CSNP中的内容,跟本机数据库里的内容进行比对,然后,根据比对结果,向DIS发出PSNP(请求其发送本机所需的LSP),或者向DIS发出(其数据库里没有的)LSP。

本节会详细介绍CSNP和PSNP的格式,并会详谈IS-IS路由器是如何利用两种协议消息,向邻居路由器展示(本机所持LSP)、请求(本机所缺LSP)以及间接确认(本机所收)LSP的。

6.2.1 数据库同步过程中所使用的IS-IS PDU

4种基本类型的IS-IS PDU中,有3种都会在数据库同步过程中用到,如下所列。

链路状态PDU(PDU类型字段值为18[L1]或20[L2])。

完全序列号PDU(PDU类型字段值为24[L1]或25[L2])。

部分序列号PDU(PDU类型字段值为26[L1]或27[L2])。

第5章已经介绍过了邻居路由器之间如何泛洪LSP,以及IS-IS路由器如何利用序列号PDU来确认收到的LSP,但是并未深入探讨序列号PDU。序列号PDU为数据库同步过程中所不可或缺,本章会做详细讨论。

图6.15所示为完全序列号PDU(CSNP)的格式,其作用是向L1或L2邻居路由器展示本机数据库的内容。L1和L2 CSNP的(PDU)类型字段值分别为24(0x18)和25 (0x19)。

源(路由器)ID 字段,由生成(LSP 的)路由器的 SysID(6 字节)和电路 ID (1字节)组成。电路ID总是被设置为0x00。

起始LSP ID和结束LSP ID字段,这两个字段共同定义了一个连续的LSP ID的范围,涵盖了本CSNP所能“展示”的所有LSP ID。这两个字段值不必是真实的LSP ID。比方说,若某台IS-IS路由器只需通过单条CSNP消息,便能完全“展示”其数据库里的LSP,则这条CSNP消息中的起始LSP ID字段值和结束LSP ID字段值将分别为0000.0000.0000.00.00和ffff.ffff.ffff.ff.ff。这两个字段值所定义的LSP ID的范围,涵盖了那条CSNP消息所能展示的所有LSP ID。要是那台IS-IS路由器需发出多条CSNP消息,才能完全“展示”其数据库里的LSP,那么在每条CSNP消息中,那两个字段值所定义的LSP ID的范围,将会涵盖本CSNP消息所要展示的LSP ID。比如,该IS-IS路由器为完全展示本机数据库,需要发出两条CSNP消息。那么,若在第一条CSNP消息中,那两个字段值分别为 0000.0000.0000.00.00 和 0000.abcd.1234.00.00;则在第二条CSNP消息中,那两个字段值将会是0000.abcd.1234.00.01和ffff.ffff.ffff.ff.ff。因此,接收(CSNP)的邻居路由器通过解读那两个字段,不但能识别出“一串”CSNP中的“首尾”,而且还能发现“一串”CSNP消息当中是否有一条或多条传丢。

有以下两种TLV结构可能会在CSNP中露面:

LSP条目TLV;

认证信息TLV。

认证信息TLV主要是起对IS-IS协议消息进行安全认证的作用,将在第9章讨论。LSP条目TLV是CSNP中不可或缺的TLV,其作用是唯一地标识(需通过CSNP消息展示的)LSP。该TLV结构标识LSP的方法是,在其值(V)字段中包含该LSP头部中的剩余生存时间、LSP ID、LSP序列号以及校验和字段。图6.16所示为LSP条目TLV的格式,其类型字段值为9(0x09)。

图6.17所示为部分序列号PDU(PSNP)的格式,顾名思义,它所包含的内容就是本机数据库里部分 LSP的序列号。利用 PSNP,IS-IS路由器既可以直接确认本机(通过点到点链路)收到的LSP,也可以向L1或L2邻居路由器请求本机所需要的LSP。PSNP的PDU类型字段值为26(0x1A)(L1)和27(0x1B)(L2)。

源(路由器)ID 字段,由生成(LSP 的)路由器的 SysID(6 字节)和电路 ID (1字节)组成。电路ID总是被设置为0x00。

与CSNP一样,在PSNP内,也可以包含认证信息TLV和LSP条目TLV,其中,后者是用来展示(本路由器所持)LSP的基本TLV结构。

6.2.2 设置路由消息标记和序列号消息标记

第5章已经简要介绍过在(LSP)泛洪过程中会用到的发送路由消息(Send Routing Message,SRM)标记。现在,来重新回忆一下。

SRM标记是一种内部标记。IS-IS路由器会基于(其接口所连)每条链路,为存储在LS数据库内的每条LSP,创建一组SRM标记。也就是说,若一台IS-IS路由器有5个接口(连接了5条链路),其LS数据库内有20条LSP,则每条LSP需与5个SRM标记“挂钩”,共需创建100个SRM标记。当IS-IS路由器决定要通过某特定接口(链路)发出LSP时,便会让相关LSP“打上”为该接口(链路)分配的SRM标记。IS-IS路由器会每隔一段时间(这段时间被称为LSP最短发送间隔期[minimum LSP transmission interval]),扫描一次LS数据库。只要“发现”有LSP“打上”了为点到点链路分配的SRM标记,IS-IS路由器就会通过相应的点到点链路向外发送。IS-IS路由器通过广播链路外发LSP的行为要稍微复杂一点:路由器会每隔“LSP 最短发送间隔期”,扫描一次 LS 数据库,然后从一组LSP(这组LSP都“打上”了为此广播接口[链路]分配的SRM标记)中随机选择一条,然后向外发送[5]。IS-IS路由器(在广播链路上)随机选择LSP,然后向外发送,可大大降低多台路由器同时向DIS发送同一条LSP的概率。

(设置或清除)SRM标记,不单是(LSP)泛洪机制的一部分,同时也是LS数据库同步机制的一部分。当 IS-IS 路由器通过某特定接口(链路)发出 LSP 时,便会把相关LSP“打上”为该接口(链路)分配的 SRM 标记。对于广播链路(接口),IS-IS 路由器只要通过其发出了LSP,就会立即清除相关SRM标记;而对于点到点链路(接口),只有当发出的LSP得到了(邻居路由器的)确认,IS-IS路由器才会清除相关SRM标记。在这一块,SRM 标记所起的作用有点像 OSPF 链路状态发送列表。不过,两者之间有一处最主要的区别,那就是:OSPF链路状态发送列表与邻居路由器“挂钩”(作为OSPF邻居数据结构的一部分),而SRM标记只和接口(链路)“挂钩”。

在LS数据库的同步过程中,IS-IS路由器还会(为LSP)设置一种名叫发送序列号(Send Sequence Number,SSN)的内部标记。与设置SRM标记一样,IS-IS路由器也会基于每个参与IS-IS进程的接口(IS-IS接口),为每条LSP设置SSN标记。一条LSP被打上SSN标记,即表明在相关IS-IS接口(与该SSN标记相关联的IS-IS接口)外发的PSNP中,会“展示”这条LSP。当这条LSP的SSN标记被清除时,则表示IS-IS路由器已经发出了“展示”该LSP的PSNP。在LS数据库同步期间,IS-IS SSN标记所起的作用类似于OSPF链路状态请求列表。再次重申,与SSN标记挂钩的是路由器接口,并非某台具体的邻居路由器。

在点到点网络环境和广播网络环境中,IS-IS 路由器对上述两种标记的使用,以及相互之间同步LS数据库的规程都各不相同。以下两节将详述在这两种类型的网络环境中,IS-IS路由器之间同步LS数据库的规程。

6.2.3 点到点网络环境中的LS数据库同步

通过点到点链路新近建立起邻接关系时,两台IS-IS路由器都会基于与此链路相连的接口,为所有LSP设置SRM标记,然后发出CSNP,相互“展示”本机LS数据库里的全部内容。至于发出的是L1 CSNP还是L2 CSNP,则要视所建立的邻接关系类型(L1或L2)而定。收到邻居路由器发出的CSNP之后,每台IS-IS路由器都会拿CSNP中所“展示”的LSP,跟本机数据库里的LSP进行比对。比对方式是,根据CSNP中“起始LSP ID”和“结束LSP ID”字段值所定义的LSP ID的范围,按序对CSNP 的LSP ID(即CSNP所含LSP条目TLV结构中的LSP ID字段值)和本机数据库里的LSP ID进行比对。每进行一次比对,IS-IS路由器都会采取以下动作之一。

若CSNP中有LSP ID与本机数据库所含LSP的LSP ID相同,则清除与相关接口(用来连接点到点链路的接口)“挂钩”的LSP的SRM标记。

若发现了本机未知的LSP(即CSNP所含LSP条目TLV结构中的LSP ID字段值,未在本机LS数据库里“露面”),则针对此LSP在本机LS数据库创建一条序列号字段值为0的记录,表示“暂缺”该LSP的内容。IS-IS路由器不会为序列号字段值为0的LSP设置SRM标记,这意味着,不能泛洪此类LSP。然后,为这条新近创建的LSP的记录设置SSN标记。于是,一条“展示”该LSP的PSNP会发往(通告该CSNP的)邻居路由器,以请求其发送该新版LSP。

若本机LS数据库里所含LSP的“版本”新于CSNP中所“展示”的LSP,IS-IS路由器会清除针对该LSP设置的SSN标记,并同时为其设置与(接收CSNP的)接口“挂钩”的SRM标记,然后以单播方式向(通告该CSNP的)邻居路由器发送这条新版LSP(即这条LSP的最新版本)。

若存储在本机LS数据库里的LSP的“版本”要比CSNP所“展示”的LSP“老”,IS-IS路由器会清除针对该LSP设置的SRM标记,并同时为其设置与(接收CSNP的)接口“挂钩”的SSN标记。如此一来,本机数据库里老版LSP便不得泛洪而出。然后,IS-IS路由器还会以单播方式向(通告该新版CSNP的)邻居路由器发送“展示”该LSP的PSNP,以请求邻居路由器,发送该新版LSP。

若存储在本机LS数据库里的LSP,其序列号和生存时间都不为0,其LSP ID也在包含在(收到的)CSNP的“起始LSP ID”和“结束LSP ID”字段值所定义的LSP ID的范围之内,但该CSNP的条目TLV结构的LSP ID字段中却并没有包含该LSP ID,则IS-IS路由器会基于(接收该CSNP的)接口,为这条LSP设置SRM标记,然后以单播方式向(通告该CSNP的)邻居路由器发送这条LSP。

在点到点网络环境中,PSNP还起对收到的LSP进行确认的作用。当IS-IS路由器向邻居路由器发送LSP时,便会将其“打上”为相关接口(外发LSP的接口)分配的SRM标记。IS-IS路由器会每隔5秒钟(即minimumLSPTransmissionInterval[LSP最短发送间隔期]),重传已基于接口打上了SRM标记的LSP,以及在5秒钟之前未发送成功的LSP。收到了邻居路由器发出的 PSNP,表明已经收到了自己之前发出的 LSP时,IS-IS路由器便会清除为这条(些)LSP设置的SRM标记,这意味着不再重传那条(些)LSP。

当IS-IS路由器(通过点到点链路)收到LSP时,会采取以下动作之一。

若收到的LSP的“版本”新于本机LS数据库里的LSP(或本机数据库里包含了一条序列号为0的该LSP的记录),则以这条新版LSP替换数据库里现有的LSP。然后,基于所有接口(除接收该LSP的接口),为这条新版LSP设置SRM标记,同时清除为接收该LSP的接口设置的SRM标记,好让这条新版LSP能泛洪至所有邻居路由器(通告此LSP的邻居路由器不在泛洪之列)。

若本机LS数据库里的LSP的ID与收到的LSP的ID不匹配,则在数据库中安装收到的LSP。然后与收到“新版”LSP时相同(详见上一条所述),再基于所有接口(除接收该LSP的接口),为这条LSP设置SRM标记,同时清除为接收该LSP的接口设置的SRM标记,好让这条LSP能泛洪给所有邻居路由器(通告此LSP的邻居路由器除外)。

若收到的LSP的“版本”比本机LS数据库里的LSP要“老”,则基于接收(这条老版LSP的)接口,(为新版LSP)设置的SRM标记,然后通过该接口,向(通告这条老版 LSP 的)邻居路由器发送本机数据库里的新版 LSP。最后,清除基于此接口为此LSP设置的SSN标记。

若收到的LSP的“版本”与本机LS数据库里的LSP相同,则清除基于接收(这条LSP的)接口为这条LSP设置的SRM标记;但会同时基于该接口为这条LSP设置SSN标记,其目的是,通过该接口发出PSNP,向邻居路由器确认本机收到了这条LSP。

如本节第一段所述,IS-IS 路由器之间邻居关系一经建立,双方都会基于(用来建立邻接关系的)接口,为存储在本机数据库里的所有LSP设置SRM标记。这样一来,即便邻居路由器未发出 PSNP,请求(本路由器)发送 LSP,本路由器仍会在 5 秒的minimumLSPTransmissionInterval(LSP最短发送间隔期)之后,向邻居路由器发出LSP,若邻居路由器仍未收到,则会每隔5秒发送一次,直至邻居路由器确认收到为止。

这也意味着,IS-IS路由器之间建立邻接关系时,由于LSP泛洪是由SRM机制所触发,因此即便(IS-IS路由器之间)不互发CSNP,数据库同步也照样会进行。发送CSNP只是对数据库同步过程进行了优化,好让邻居路由器之间只交换本机需要的LSP。

6.2.4 广播网络环境中的LS数据库同步

在广播网络环境中,所有OSPF路由器都会跟DR相互同步LS数据库,与此相同,IS-IS路由器也会跟DIS相互同步LS数据库。但相同之处仅限于此。

主要区别在于:发往DR/BDR和DROthers的OSPF路由协议数据包的目的多播地址各不相同,而发往DIS和其他所有路由器的IS-IS路由协议消息的目的多播地址却完全相同。当然,L1和L2 IS-IS路由协议消息的目的多播地址还是会有所区分。CSNP、PSNP以及 LSP 都以多播方式发送,能被接入同一广播网络的所有路由器同时接收。所以说,若路由器A发出PSNP,请求(其邻居路由器B)发送某条LSP,则接入同一广播网络、同样“缺少”这条LSP的其他路由器也会“看见”这条PSNP(即缺少这条LSP的其他所有路由器都会得知,请求该LSP的PSNP已经发出)。同理,只要任何一台邻居路由器发出了LSP,接入同一广播网络的所有路由器都能收到这条LSP,可视需求,将其拷贝存储进本机LS数据库。

DIS 会每隔 CompleteSNPInterval(CSNP 发送间隔期),发出“展示”其数据库完整内容的 CSNP。CompleteSNPInterval通常为10秒,该值可以配置,取值范围为1~65535秒[6]。CSNP会以多播而非单播方式发送,接入广播网络的所有路由器都能接收得到。通过广播网络接口收到CSNP时,路由器也会按序对CSNP 的LSP ID与本机数据库里的LSP ID做一番比对,这跟6.2.3节所描述的通过点到点接口收到CSNP时,没任何区别。

不过,当IS-IS路由器通过广播接口,以多播方式发出LSP时,会清除基于该接口为LSP设置的SRM标记,并不会继续保留SRM标记(通过点到点接口发出LSP时,IS-IS路由器会保留基于该接口设置的SRM标记)。这是因为接入广播网络的所有路由器都会以多播方式发送CSNP,这也起到了“间接”对收到的LSP进行确认的效果。若某台非DIS路由器发出了LSP,但却没有被DIS接收,只要该DIS在随后发出的CSNP中未能“呈现”出该LSP,那台非DIS路由器就会得知。然后,便会重新发送这条LSP。同理,若广播网络内的某台路由器未能收到(DIS 发出的)LSP,当(DIS)重新发送 CSNP 时,这台路由器必会得知,随即便会发出PSNP,请求DIS发送这条LSP。

(接入广播网络的IS-IS路由器)在收到LSP时的处理方式也跟6.2.3节所述基本相同,但有一处例外,那就是只要收到的 LSP 的“版本”不“老”于存储在本机数据库里的LSP,便不会为此LSP设置SSN标记。这便表明,IS-IS路由器不会发出PSNP,来确认收到的此类LSP。这一处理方式可避免这样一种情况的发生:接入广播网络的多台路由器同时对收到的同一条LSP进行确认。接入广播网络的所有路由器只要都定期发出CSNP,就能在不降低可靠性的情况下,对收到的LSP进行间接确认。

5.1.2节曾提到,IS-IS路由器会每隔minimumLSPTransmissionInterval(LSP最短发送间隔期),扫描一次 LS 数据库,从一组 LSP(这组 LSP 都“打上”了为广播接口[链路]分配的SRM标记)中随机选择一条,然后通过广播接口向外发送[7]。该机制能够让(接入广播网络的)多台路由器尽可能去分摊 LSP 更新过程所带来的负担。由于在广播网络环境中,所有IS-IS路由协议消息都以多播方式发送,因此在数据库同步期间,网络内的每一台路由器都对(其他所有路由器的)数据库同步的进展情况一清二楚。也就是说,若一台路由器发出 PSNP,请求邻居路由器发送一条(或多条)LSP,则该路由器的“举动”会暴露在“众目睽睽”之下。假设该路由器所请求的是新版LSP,而网络内所有其他路由器可能都持有该LSP的拷贝,但只有DIS会发出该路由器通过PSNP所请求的LSP,这便避免了同一条LSP的多份拷贝在网络内“泛滥”。在数据库同步期间,OSPF路由器只跟DR进行同步(亦即DROthers发出的OSPF路由协议数据包,只有DR/BDR才能收到),而定期发出CSNP的DIS所起的作用更像是一个参考点。同理,在广播网络环境中,以多播方式“冲着”某台路由器发出的LSP(即这台路由器之前发出了PSNP,请求邻居路由器发送这条LSP),由于此类LSP以多播方式发出,因此能够被需要这条(些)LSP的多台路由器接收。

6.2.5 IS-IS排障方法1:学会解读路由器生成的日志记录及Debug输出信息

排查OSPF故障时,若绞尽脑汁都查不出邻居路由器之间LS数据库不能同步的原因,那就有必要去解读路由器生成的与数据库同步有关的日志记录。这一排障思路同样适用于排除IS-IS路由器之间LS数据库不能同步的故障。图6.18和图6.19所示为两台IS-IS路由器同步各自的LS数据库时,生成的日志记录。

这两台路由器一台是Cisco路由器(Cisco8),另一台是Juniper路由器(Juniper6)。请读者在阅读这两台路由器生成的与数据库同步有关的日志记录时,回答以下问题。

两台路由器的互连接口(用来建立IS-IS邻接关系的接口)的MAC地址分别是什么?

两台路由器的互连接口(用来建立IS-IS邻接关系的接口)的IP地址分别是什么?

两台路由器的互连接口的电路类型分别是什么,是L1-only、L2-only还是L1/L2?

两台路由器之间建立的是L1还是L2邻接关系?

每台路由器发出的LSP的LSP ID字段值分别是什么?

从每一台路由器的视角来看,首次验证邻居之间具备双向连通性的时间点是什么?

6.2.6 IS-IS排障方法2:学会比较不同IS-IS路由器的LS数据库

一般而言,同一区域内IS-IS路由器间的LS数据库不会发生不同步现象,需要LS数据库进行比较的情况可谓是凤毛麟角。6.1.8节介绍的比较OSPF LS数据库的方法同样适用于比较IS-IS数据库:计算存储在每台IS-IS路由器的数据库里的LSP的校验和之和,然后加以比较,就能很快发现LS数据库是否同步。

图6.20和图6.21所示为前例中已经完成同步的那两台路由器的LS数据库的内容。请注意,Juniper路由器为L2-only;Cisco路由器为L1/L2,因此该路由器在L1和L2数据库里都分别存储了LSP。

6.3 复习题

1.有哪几种 OSPF 路由协议数据包会为数据库同步所用,请分别说出每一种数据包的名称和类型字段值。

2.OSPF DD(数据库描述)数据包中I和M位的用途是什么?

3.在哪些OSPF信息单元中会出现选项字段?

4.OSPF选项字段中E位的含义是什么?

5.请说出OSPF邻居数据结构的用途,这一数据结构存储了哪些信息?

6.请说出OSPF链路状态发送列表(Link State Transmission List)的用途。

7.请说出OSPF链路状态请求列表(Link State Request List)的用途。

8.OSPF路由器之间交换数据库之前,如何确定主/从(Master /Slave)路由器?

9.OSPF 路由器之间进行数据库交换时,主路由器是如何对数据库的交换进行控制的?

10.请说出8种OSPF邻居状态,以及每一种邻居状态的含义。

11.在广播网络环境中,DROthers之间经常会存在哪一种邻居状态?

12.生成图6.9所示日志记录的那台路由器最终成为了DR还是BDR?

13.请仔细观察图6.9和图6.10所示的输出,然后说出在数据库同步期间,哪台路由器为主路由器,哪台路由器为从路由器。

14.有哪几种IS-IS路由协议消息会为数据库同步所用?

15.通过点对点接口收到LSP时,IS-IS路由器的确认方式是什么?

16.通过广播接口收到LSP时,IS-IS路由器的确认方式是什么?

17.接入广播网络的IS-IS路由器如何得知本机所需的LSP的拷贝,如何请求邻居路由器发送该LSP的拷贝?

18.生成图6.18所示日志记录的路由器的AID是什么?其邻居路由器的AID是什么?

19.生成图6.18和图6.19所示输出的那两台路由器是L1-only、L2-only还是L1/L2?

[1].译者注:原文是“So when two OSPF neighbors are comparing LSAs, one of the neighbors manages the exchange”。

[2].本例扩充自RFC 2328 10.10节所举示例,以及Routing TCP/IP, Volume I 445~447页所载示例。

[3].译者注:原文是“The actual events causing the state changes are discoveries or changes of information included in the packets”。

[4].实际上,ISO 10589甚至都没有要求IS-IS邻居路由器之间通过点到点链路,定期向对方“展示”本机数据库,只是有些厂商为了优化自己的的IS-IS实现,在通过点到点链路互连的路由器之间引入了这一机制。

[5].某些IS-IS实现(即某些厂商的IS-IS路由器)可能会在每次扫描时,随机选择(发送)不止1条LSP,但条数不能太多。ISO 10589的建议是:数不过十。

[6].虽然CompleteSNPInterval的取值范围很大,但没有任何理由去改变其默认值。第5章曾经提到,IS-IS与OSPF不同,前者并没有一种专门用来对LSP的接收进行确认的协议消息。在广播网络环境中,IS-IS的替代解决方案是,让路由器发出CSNP,以间接的方式对收到的LSP进行确认。因此,把CompleteSNPInterval设得过高,会降低路由器对所收LSP的确认频率,而将其值设得过低(低于10秒),也不会对性能有明显的改善。

[7].某些IS-IS实现(即某些厂商的IS-IS路由器)可能会在每次扫描时,随机选择(发送)不止1条LSP,但条数不能太多。ISO 10589的建议是:数不过十。

相关图书

Web应用安全
Web应用安全
企业“IPv6+”网络规划设计与演进
企业“IPv6+”网络规划设计与演进
“IPv6+”网络技术创新:构筑数字经济发展基石
“IPv6+”网络技术创新:构筑数字经济发展基石
社交网络对齐
社交网络对齐
华为HCIA路由交换认证指南
华为HCIA路由交换认证指南
非常网管 IPv6网络部署实战
非常网管 IPv6网络部署实战

相关文章

相关课程