EIGRP(Enhanced Interior Gateway Routing Protocol)   增强网关内部路由线路协议O3

DUAL和SIA





实验环境：
所有路由器的metric weight 0 0 0 1 0 0 只使用delay作为Metric。链路两端接口使用如图标示的延迟。
注：因为delay是以10为单位的，按照EIGRP带宽计算公式来算，以我们更改的基数X256就是实际的Metric。

此实验，旨在理解Query Replay，加深对RTP序列号的理解

解析：
1.R3去往R4环回口的路由，按图来说，只有S没有FS。
P 4.4.4.4/32, 1 successors, FD is 1024
via 13.0.0.1 (1024/768), FastEthernet1/1
如果没有FS的情况下，当前S断掉，会针对丢失的路由去向邻居发送查询(说邻居也不是很客观)

2.断掉R3面向R1的接口，R3首先会执行本地查找，针对于这条路由，没有FS，将路由变为主动状态，针对这条路由去发组播查询，R2会接收到：




指明，路由不可达。

3.R2接收到这个请求，因为R3是自己去往4.4.4.0的S，R2会执行一个本地运算，看是否有针对这条路由的FS
P 4.4.4.4/32, 1 successors, FD is 1280
via 23.0.0.3 (1280/1024), FastEthernet0/0-------------已丢失。
via 12.0.0.1 (5888/768), FastEthernet1/0

4.R2将下一跳为R1的FS放进Replay扔给R3 至此(因为R2本地有针对此路由的FS，执行本地计算，将FS发送给R3，R2的路由状态一直是被动，只有R2也找不到的时候才会变为主动)




5.R2发送Update组播通告所有包含在Replay的路由。





DUAL实验二：





R1——R4的Metric从2增加到10.这时候，R1去往4.4.4.0没有FS，超过了FD。R1会发送查询，来寻找是否有新的路径去往4.4.4.0
R1发往R4的查询：




R4的Replay：





R1会向所有的邻居通告自己新的Metric： R1——R5





Update发送过后，紧跟一个Query，来询问邻居是否有更好的路径去往这个目的地





R5原来去往4.4.4.4/32就有一个FS。所以：Replay中包含自己的FS





R1发给R3，告诉R3去往4.4.4.4/32的最新Metric.





R1发送Query给R3，询问最佳路径，R3没有FS，且超过了自己的FD，会返回给R1一个不可达消息。









R3接收到这个消息，同样，FD的改变超过了自己的原始FD，而又没有FS。R3在自己的路由表中将这条路由变为主动状态，向自己的邻居发送查询。R3此时针对于4.4.4.4/32的Metric无从知晓，发送不可达消息给R1，询问去往4.4.4.4/32的路径





R1将自己新的Metric通过Replay传给R3





R1Update发送给R2，通告新的Metric:





R1也将查询发向R2,询问是否有更好的路径：





R2从R3接收到新的METRIC，也会向R1发送查询，询问是否有更好的路径：





R1返回给R2一个自己去往4.4.4.4/32的更新METRIC路径





R2这时候已经从R3(即自己的S)接收到了新的Metric通告：





最后看下R2——R3这期间的过程，在R1询问R2的同时，R2和R3就进行了交互。过程如下：
R3发给R2的查询：




R1本地收到所有Replay以后，经过计算，选出自己的S和FS。发送更新消息，给邻居。

只有在收到所有的回复消息以后，才会开始重新计算。计算完成后，路由状态回归被动，同时通告Update消息。




如果一直没有收到某一个回复怎么办？

SIA(Stuck-In-Active):
路由器在一些情况没有收到发出的每一个查询的回复，在开始扩散的时候，一个活动计时器，被设置为3MIN。在活动计时器超时以后，如果还没收到回复，那这条路由被宣告卡在活动状态，没有答复的邻居将从路由表中删除。

本文出自 “_癫人。” 博客，请务必保留此出处http://zhangchiccie.blog.51cto.com/1579309/686690