
前面讲了EIGRP的邻居形成和可靠传输。路由器动态地发现邻居后,将向他发送一个更新(Update),其中包含有关自己知道的路由信息,同时也将从邻居那里收到这样的Update。收到这些Update之后,路由器将把他们放在自己的拓扑表里。拓扑表里包含邻接路由器通告的所有目标网络,也就是说,每台路由器都将其邻居的路由表存储在自己的拓扑表里。如果邻居通告给我一条路由,则说明他正在使用该路由来转发分组,这条规则是所有距离矢量路由协议都必须严格遵守的规则,大家要记住这点!这里要补充说明的一点是EIGRP为其支持每种网络协议(IP、IPx、IPv6、Apple Talk)维护一个邻居表,同样也分别维护一个拓扑表。有了拓扑表之后路由器会进行DUAL的计算,从而得到好的路由条目存放进路由表里去。
也就是Neighbor Relationship(Neighbor Table)---->RTP(Topology Table)---->DUAL(Route Table)这么个顺序。
那么这个DUAL是个什么情况呢,他具体是怎么根据拓扑表得出路由表呢,这里要介绍下下面几个概念。
首先是FD和AD。FD是可行距离,也就是我自己到目标网络去的距离,当然这个也不是真正的距离,而是metric。AD是通告距离,也就是通告给我到目标网络去的邻居他到目标网络去的metric。假如如下:
用R3模拟一个与R2相连的网络,R2到网络R3的开销就叫AD,R1到网络R3的开销叫FD。这里要特别注意一点,很多书上都说FD是当前路由器到下一跳路由器的开销加上下一跳路由器到目的网络的开销,这种说法其实并不科学,这里并不是个单纯的加法,这要从路由器对于metric的计算上说起。
EIGRP在通告时并不是将一个具体的metric值通告出去,而是将跟链路相关的一些具体参数通告出去的,让收到的路由器自己去比较计算,而这些参数就是跟那几个key值相关的东西,比如,带宽、延迟、负载、可信度、MTU。默认情况下metric的计算只考虑带宽跟延迟。还是上面那幅图,在默认情况下,R1到网络R3去的metric考虑的带宽是这段链路上最小带宽,而延迟是链路的延迟之和。比如R1跟R2这段的带宽是1M延迟是100微秒,而R2跟R3这段的带宽是2M延迟是50微秒,那么R1在计算到R3去的metric时就取R1跟R2这段的小带宽1M,延迟是两部分之后100+50=150微秒。这里又有一点需要强调的是这个带宽是指自己到目标网络去整段链路上的出向接口的带宽,比如说上图中R1考虑的它的s0/0的带宽和R2的f0/0的带宽,而与R2的s0/0的带宽一点关系都没有,这也很好理解嘛,metric翻译成中文叫做度量标准,我们把它称作开销,也就是所谓的代价,你到目标网络去要花多大的代价,我们当然希望代价越小越好,所以选路时总是选metric小的。既然是代价,我们一般当然是考虑自己的代价,就是我把数据发过去我要花多大的代价,至于别人收数据需不需要花费和花费多大代价那是他要考虑的。就比如你找别人办事,你要跟别人送礼,你买这礼物花多少钱这就是你的代价,你要考虑你花多少钱才合适,你当然是希望他能在帮你把事给办了的基础上花最少的钱,至于他收你礼物要花多大代价那是他要考虑的事情(他得考虑收你这么一礼物给你办这事值不值,他有没有风险什么的),所以这点也要搞清楚。默认情况下EIGRP的metric=(10000000*K1/BW+Delay*K3/10)*256,前面我们也说了metric是代价,既然是代价,那么当然是链路带宽越大代价越小,延迟越小代价也越小,所以带宽跟metric成反比关系,而延迟跟metric成正比关系。至于为什么带宽要用10的7次方去除而延迟要除以10,这是因为EIGRP要综合考虑各种因素对metric的影响,你总不能说带宽由1K变成1000K,metric只由0.1变成0.001,而延迟由10微秒变成8微秒metric就由10变成8了,这样考虑也太不科学了,显然一个网络从1k变成了1M他的性能提升了很多,传输速率也快了很多,而你就算由延迟10微秒变成了8微秒,你对于数据传送也没起到多大的影响,所以,为了综合和平衡各种因素对metric计算的影响带宽是用10的7次方去除的,而延迟是除以10的,注意公式中带宽的单位是K而延迟的单位是微秒。K1和K3就是对应的带宽和延迟的一个比例系数,大家应该都还记得update报文中K1和K3的值都是1,其实这个也是可以调的,就是说,当你自己觉得将带宽和延迟的比例调成一个什么程度是比较合理的时候你来调的,这里只是思科在项目实验中通过对比觉得一个比较合理的值,一般情况你不要去动他,因为这个值已经是比较OK的啦。那么后面乘以256又是怎么回事呢?这是因为前面括号里面的公式是IGRP关于metric的计算,而IGRP的报文格式中metric字段是24的bit,在EIGRP中,这部分被改成了32位,增加了8位也就是2的8次方,刚好256,所以这里要乘以256,关键是用于兼容IGRP。关于EIGRP在非默认情况下metric的计算大家就自己去找资料看吧,上次NP课萌爷试着改了下其他几个K值后得出的metric值跟公式算出来的不一样,反正很吐血,大家有兴趣把他整出来然后发个帖子给我们分享分享。
说了这么一大堆关于K值计算的问题,我们回到前面一个问题,就是上面为什么我说对于FD的计算不是单纯的加法。还是上面那幅图,R2在计算自己到网络R3去的metric时他考虑的是自己到网络R3这段链路的带宽和延迟,而R1在计算到网络R3去的的metric时他同样考虑的是R1自己到网络R3这段链路的带宽和延迟,而R2到网络R3去的带宽是2M,延迟50微秒,R1到网络R3去的带宽是自己到R2的1M与R2到网络R3的2M中较小的带宽和延迟之和,如果只是按照书上的说法是加法的话,那你这个地方对于关于带宽对metric的计算就成了10的7次方先除以1M再加上10的7次方除以2M之和后乘以256,这显然与我们所说的只算小带宽相矛盾,但是,由于关于延迟的计算是加法关系的,所以我说关于metric的计算不是单纯的加法关系。有些人可能就会想既然R1和R2在带宽的取舍上不同,那会不会出现R1的FD大于他的AD的情况呢?其实你还是看下他们的取舍就知道,肯定不会出现这种情况,因为,R1考虑的是他到网络R3去的这段链路上的最小带宽,那么当然他计算得出的metric值只会比R2大而不会比R2小。也正是由于R1对于带宽的取舍可能会与R2不一样,所以R2在给R1的Update中包含的key值让R1自己去算而不是让R1直接拿R2的metric去相加。这一块应该来说我说的还是很细了,大家可以自己去验证下是不是这么个情况。
对于上次关于EIGRP建邻居那一段,我觉得我讲的蛮坑爹,我将它归结为思科的不厚道,不给说法和萌爷分析的不透彻,以至于很多人对这部分肯定还是很不明白,所以今天我自己抓包分析了一下,大概参考了下书上给的说法和萌爷那天的一些抓包现象以及我自己的抓包现象,希望能对大家关于这部分见邻居的过程的理解有帮助,但是,还是得声明,这只是我最终根据教材和真实抓包现象得出的结果,也就是我自己的目前为止的最终看法,不能作为权威解释,大家认可的可以借鉴一下,不认可的还是自己再去摸索。我还是使用的上面那个图:
R1和R2之间使用192.168.12.0/24,R2和R3使用192.168.23.0/24,具体地址对于自己的设备编号。然后我在R1先起eigrp,R2上接着也起eigrp,R3最后起的。配置如下:
R1:
interface Serial0/0
ip address 192.168.12.1 255.255.255.0
no keepalive
clock rate 2000000
router eigrp 100
network 192.168.12.0
no auto-summary
no cdp run
R2:
interface FastEthernet0/0
ip address 192.168.23.2 255.255.255.0
duplex auto
speed auto
no keepalive
interface Serial0/0
ip address 192.168.12.2 255.255.255.0
no keepalive
clock rate 2000000
router eigrp 100
network 192.168.12.0
network 192.168.23.0
no auto-summary
no cdp run
R3:
interface FastEthernet0/0
ip address 192.168.23.3 255.255.255.0
duplex auto
speed auto
no keepalive
router eigrp 100
network 192.168.23.0
no auto-summary
no cdp run
R1与R2之间这段链路的抓包如下:
通过上图大家可以看到前11个包都是R1通过s0/0号口往外组播224.0.0.10发送Hello,这是因为我先起的R1的EIGRP进程,这个时候,这段链路只有R1一个人起了,所以指看见R1一个人往外发Hello。
第45.926000s,也就是第12个包是R2向组播发送的Hello,这说明这时R2的EIGRP进程也起来了,也开始往外发送Hello。
第45.956000s,也就是第13个包是R3向组播发送的Hello,而上一次R1向组播发送Hello也就是第11个包的时间是45.786000s,第11和第13个包之间的时间间隔跟EIGRP的Hello周期间隔5s比起来实在小很多,所以,完全可以排除第13个包是刚好到了Hello周期的情况。而且,大家可以看到第12个包(也就是R2向组播发送的第一个Hello)与第15个包(也就是R2向组播发送的第二个Hello)之间的时间间隔跟R1的这两个包(11和13)一样时间间隔也相当短,而且从第28个包往后看Hello间隔也是大概5s都是正常的,所以更加证明第13个包和第15个包不是由于Hello周期到了而发送的。至于这两个突发的Hello具体是什么意义,这个就只有思科自己知道了,大家可以根据自己的理解去看他,打开第11个包(正常Hello周期的包)和第13个包(突发的Hello包)大家可以看到,他们里面的内容一模一样:
这里我是这样理解的,前面11个周期性的Hello就好比是R1在周期性地喊:“谁想跟我处对象?”这时由于链路上没人,所以没人理他。第12个包时,R2也起EIGRP了,这时R2并没有听到R1在喊话,而且他自己也开始周期性地喊:“谁想跟我处对象?”这时R1听到了R2的喊话,于是赶紧跟R2打招呼,也就是第13个包,我觉得这个才有点像打招呼的意味。
第14个包是R1向R2发送的单播的Update,其内容如下:
通过上图可以看到他的Flags里的Init位被设置了为True,也就是1,大家可以再看看上面的Hello分组里这一位未被设置,是False,也就是0,书上说这一位被设置以指出这是初始化,这说的非常不明确,我们都知道Initial的意思是初始化,这一位被设置当然是做初始化了,这不是废话吗,但是这也怪不了写书的人,还是得怪思科太小心眼了,我们只能猜。我们打开第17个和第19个包看看,也就是R1发给R2的第二个Update和第三个Update。
通过这三个包的对比,大家可以发现,首先就是三个包的Checksum不一样,这个好理解,因为包里的内容不一样嘛,所以得出的校验和也不一样;第二就是除了第14个包的Init位为1外,其他两个都是0,这说明了第四个包确实只是用来做初始化用的,里面应该不包含路由信息。第三点就是大家可以发现第14个包的sequence是1,第17个包的sequence是2,第十七个包的sequence是3,而R1在发送初始化这个包(第14个包)之前的Hello里sequence全是0,而且第19个包(最后一个Update)之后的R1的包的sequence也全是0(这里指在这段链路稳定,R1没有收到其他更新查询报文的情况下,碰到这种情况相当于前面的过程又要重复了),包括R1回给R2的显式ACK报文。从这点可以说明,R1在向R2发送Update时会用sequence作为自己的计数器,记录自己给他发了那些Update,sequence为1表示初始化,该Update里并不携带路由信息(我自己的猜测,萌爷也是这么认为的,其实待会我可以证明我的猜测,至少我自己是这么认为的);第四点是大家可以发现第14、17、19三个包的Acknowledge的值也不一样。至于sequence和Acknowledge的值为什么不一样这不能仅从R1一方面看,要结合R1和R2双方面来看。我们从R1发送第一个Update开始看起:
只看他们的sequence和Acknowledge是不是感觉想起点什?这跟TCP的三次握手实在太像了!R1先给R2发送Update(第14个包),所以他开始计数,自己给个sequence,只不过这个sequence是从1开始的,而TCP是个随机值,由于这是第一个Update,所以不需要对谁进行确实,所以Acknowledge为0,而当R2收到R1的Update后,R2也开始发送Update(第16个包),这个Update里sequence也为1,用于表示自己的第一个Update,而Acknowledge为1,这个1是用来告诉R1我收到了你的第一个Update了,他是跟R1的sequence相同的,这样第一次握手完成;R1再发Update,sequence为2,Acknowledge为1,sequence表示自己发的第二个Update,Acknowledge用于确认R2的sequence,同理,R2回sequence2,Acknowledge2,第二次握手完成;R1再发sequence3,Acknowledge2,R2再回sequence3,Acknowledge3,至此,三次握手完成,两边协商完成,表明两边可以开始发数据了。至于为什么我没给第15个包,道理很简单,还是回到上面那个例子,当R1听到R2在喊:“谁想跟我处对象?”(12)的时候主动更R2打招呼(13,突发性Hello),该Hello好像是在问R2:“是你在喊‘谁想跟我处对象’吗?”,然后R1怕R2认为自己有什么不良企图,不等R2说话赶紧跟R2说:“我愿意跟你处对象,不过我们得商量下以后谁当家的问题,我认为应该男的当家(sequence为1,由于R2还没说话所以不用对R2的话进行回复Acknowledge为0)”(14)。R2看见有人说愿意跟她处对象赶紧回复说:“你好,是我在喊”(15,突发Hello),然后R2想不行,她得当家,于是她对R1说:“你认为男的应该当家?(Acknowledge为1)但我认为女的应该当家(sequence为1)。”R1想这不行,要是让她当家那我多没面子啊,于是对R2说:“你说女的应该当家(Acknowledge为1),但是你没我赚的钱多啊(sequence为2)。”R2想这也是的,但让他当家我得管钱,于是对R1说:“我是没你赚的钱多(Acknowledge为2),但若你愿意让我管钱我就让你当家(sequence为2)。”R1心想,这个让她管钱也可以嘛,免得我大手大脚的乱花,于是对R2说:“好吧,让你管钱(Acknowledge为2),那就这么说定了我当家了(sequence=3)。”R2这下也满意,于是对R1说:“好,以后就你当家(Acknowledge为3),那也说好了我管钱了。”于是乎,两人就谈妥了,就去派出所领证了(显式ACK),就开始把自己的好东西拿出来俩人共享(就相当于包含路由的Update了)。那么为什么在给出的抓包中没有显示包含有路由信息的Update呢,这是因为R1上我只配了个跟R2相连的s0/0的地址,没有配置其他网段,所以没看到,不过大家可以看到,当R2获得R3的路由信息后就给R1发送了携带路由信息的Update了,也就是第26个包:
第27个包就是R1对于这个Update的显式确认。
说到这个份上,我觉得我也只能理解到这种程度了,如果以后谁有更好解释,还希望大家给我们分享下。
其实我觉得我这人有点纠结,看到了什么就想说什么,本来上面我是在讲metric,然后我做了这个实验,是为了验证通过key值计算metric的,结果,突然想到了那天那个情况,忍不住就抓了包看了下,一看就收不住了,就写了上面那些东西,现在言归正传,看看路由器怎么计算metric的。
R1#show int s0/0
Serial0/0 is up, line protocol is up
Hardware is GT96K Serial
Internet address is 192.168.12.1/24
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set
Keepalive not set
CRC checking enabled
R2#show int f0/0
FastEthernet0/0 is up, line protocol is up
Hardware is Gt96k FE, address is c001.00d0.0000 (bia c001.00d0.0000)
Internet address is 192.168.23.2/24
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
通过show可以看出R1的s0/0的带宽是1544k,延迟是20000微秒,R2的带宽是10000k,延迟是1000微秒,根据带宽选小的,延迟算和,可以得出BW=1544k,Delay=20000+1000=21000微秒,10000000/1544=6476(小数点之后舍去了),6476+2100(除以10之后了)=8576,8576*256=2195456
然后去R1上:
R1#show ip route 192.168.23.0
Routing entry for 192.168.23.0/24
Known via "eigrp 100", distance 90, metric 2195456, type internal
Redistributing via eigrp 100
这也验证了公式的正确性。
通过上面的关于metric的计算,路由器能够得到去往目的网段最好的路由,从而将其添加到路由表中去,如果有多条等值路径,会将他们都加入到路由表中,用来做等价负载均衡。但如果这样的话,那么我们说他比RIP也没好到哪里去,因为当链路坏掉你也一样要查,而且同样也是等价负载平衡。这里关键一点就是EIGRP通过AD和FD的概念引出一个后继(successor)与可行后继(feasible successor)的概念。
至于,怎么引出的和引出后的好处,还是等我睡醒了再继续吧,这都早上5:20了,这下午还得补课。我本来是打算中下一起放的,结果由于中途手贱了一下就搞了那几个小时,一搞完就到现在了,所以先对不住大家了,等上完课回来,我就是连夜,也把后面的内容补齐,先睡觉去了,Good morning!
|
|
|