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。在活动计时器超时以后，如果还没收到回复，那这条路由被宣告卡在活动状态，没有答复的邻居将从路由表中删除。