EIGRP-13-弥散更新算法-停滞在活动状态

如果一台路由器参与到了针对某个目的地的弥散计算中(即将相应路由置为活动状态,并发送查询包),它必须首先等待所有邻居都返回响应包,之后它才能执行自已的弥散计算,接着选出新的最优路径,最后开始发送自已的响应包。因此,如果路由器发送处查询包,并且这个查询包导致它的多个邻居都将路由置为了活动状态,那么这台路由器现在就不仅要等待它自已的活跃邻居,还要等待邻居的邻居。如果邻居的邻居没有响应,那么邻居就不能执行自已的弥散计算,也就不能向这台路由器返回响应包,也就是说这台路由器也不能执行自已的弥散计算。如此扩展下去,一台处于活动状态的路由器会依赖于所有由于它的查询包而进人活动状态的路由器。在这些链路中,只要有一台路由器(无论出于什么原因)没有发送响应包,都会导致所有依赖于它的路由器延迟自已的弥散计算时间,可能永远无法完成自已的弥散计算,最终无法收敛。

 

EIGRP邻居路由器有多种原因无法发出响应包,现在把常见原因总结如下: 

 

■ 由于邻居路由器的CPU超负荷运转,导致它无法及时回复响应包,或者根本无法处理所有人站数据包,其中包括EIGRP数据包;

■ 由于链路上的传输质量不良,导致数据包丢失; 

■ 由于低带宽链路的拥塞导致数据包延迟或被丢弃; 

■ 由于网络拓扑过于庞大或过于复杂,导致查询范围过大,或者导致单条链路或单个节点的故障波及了太多网络前缀。

 

处于活动状态路由器的相互依赖关系,在某种程度上是EIGRP的致命弱点。因此EIGRP实施了多个机制来应对这一问题。

 

当一台路由器初次发出查询包时,这条路由的活动计时器(Active Timer)就开始计时了。活动计时器的默认值是3分钟,工程师可以将它设置为1-65535分钟之间的任意值,也可以在router eigrp配置模式下,使用命令timers active-time将它设置为无限期。如果在活动计时器超时后,路由器还没有收到所有它所等待的响应包,那么 这条正在查询的路由就处于SIA (停滞在活动状态)状态中。路由器这时会从邻居表中移除那些没有响应的邻居,从而导致它们之间的邻接关系断开;弥散计算会认为这些邻居回复了一个无穷大的度量值。

 

 EIGRP中的SIA状态非常糟糕,而且通常难以诊断。在最糟糕的情况下,一台未响应的路由器能够导致大范围网络无法在活动计时器规定的时间内收敛。此外, SIA 状态导致的邻接关系丢失能够引发网络的不稳定性,因为这样一来,通过那个邻居学到的所有网络都会被冲刷掉,只有等Hello间隔后,邻居关系重新建立起来之后,路由器才会再次学到这些路由。

 

在最初的EIGRP部署环境中解决SIA状态带来的问题尤为棘手,因为如果一个邻居在活动计时器超时前,都没有发送响应包,路由器就会断开与这个邻居之间的邻接关系, 即使这个邻居本身并不是使它进人SIA状态的根本原因。很显然,这样做可以使路由器摆脱SIA状态,但同时这种做法也惩罚了一个可能无辜的路由器,并且对于定位真正的故障点毫无帮助。为了能够尽量牵制和定位真正的故障点,即影响查询包/响应包无法正常交换,导致弥散计算一拖再拖;最新的EIGRP实施方案中使用了SIA查询包和SIA响应包。 

 

如果当活动计时器规定的时间过去了一半,一个邻居还没有通过自已的响应包对 路由器发出的查询包做出响应,路由器将会向这个邻居发送SIA查询包o SIA查询包 所包含的意思是“你还在处理我的查询包吗”。如果邻居能够接收并处理这个SIA查 询包,它将会马上以SIA响应包作为响应o SIA响应包所包含的内容可以是“是的, 我仍在等待我的邻居向我发送响应包”,也可以是“不,计算已经完成;这是对于这个 目的地,我的当前度量值”。无论是哪种内容,邻居都会马上发送SIA响应包,并将 其当作对SIA查询包的响应;对于回应SIA查询包这件事来说,没有什么好等的。收到SIA响应包后,路由器会重置活动计时器,为弥散计算提供更多的时间o SIA查询 包最多可以发送3次,每次都是在经过了活动计时器规定时间的一半时发送。如果路 由器发出了第3个SIA查询包,也收到了第3个SIA响应包,弥散计算还没有完成,那么当再次经过了活动计时器规定时间的一半时,路由器会断开与这个邻居的邻接关 系。如果路由器没有收到邻居针对SIA查询包所返回的SIA响应包,那么在活动计时 器的后一半时间超时后,它也会断开与这个邻居的邻接关系。活动计时器的默认设置是180秒, 3个连续的SIA查询包能够把弥散计算的时间延长到4×90=360秒(90秒后发送第1个SIA查询包,每个SIA查询包可以争取到90秒的时间)。 

 

如果两个邻居之间的通信没有出现问题的话,路由器会在发出SIA查询包后,几乎立即收到SIA响应包。然而如果两个邻居之间的通信存在问题,这个问题也很可能 就是导致普通查询包和响应包无法交换的原因,那么这个SIA查询包也很有可能收不 到响应。因此这两台路由器之间的邻接关系会被断开,它们之间的连接很可能就是导 致SIA状态的根本原因。

 

下例展示了路由进人SIA状态的案例。3台路由器串联在一 起,路由器X连接路由器Y,路由器Y连接路由器Z (路由器Z没有出现在拓扑中),它们都运行IPv4 EIGRP。活动计时器保留默认设置：3分钟。拓扑中每个接口的保持间隔增加为10000秒,路由器Y连接路由器Z的接口上应用了一个ACL,用来丢弃所有人向数据包。路由器x上的本地环回接口被关闭后,路由器x向路由器Y发送 查询包,路由器Y继而向路由器Z发送查询包。但由于ACL发挥作用,路由器Y无 法收到路由器z发出的响应包,从而使这条路由进人SIA状态。下面这个案例记录了 EIGRP对于这个问题的处理过程。

 

注意,当一个目的地处于活动状态时,路由器仍可能接收对于这个目的地的查询包。考虑下图所示拓扑。

 

 

图中所示的环境是这样的。 

■ R1直连着一个LAN网络。

■ R2和R3都会将R1作为去往LAN的下一跳, R1的CD值是0。

■ R2和R3都不会把自已作为去往R1 LAN的可行后继。

 

■ R1上的LAN接口关闭后,R1会向它的所有邻居发送有关这个网络的查询包, 并在其中通告一个无穷大的距离。假设R1向其邻居发送数据包时的延迟很大,这时R2首先收到了这个查询包。

■ 收到这个查询包后, R2不再将R1作为后继(R1现在无法通过R2上的FC检查了),同时R2又没有可行后继,这时它会进人活动状态,并向R3发送自已的查询包。

■ 同一时间,假设R3收到了R1的查询包。对于R3来说,情况也是一样的。 R3也会进人活动状态,并向R2发送自已的查询包;这时R2的查询包已经传输在R2-R3链路上了。 

■ 最终的结果是: R2和R3都向对方发送了各自的查询包,它们也都会收到一 个查询包,查询的是已经处于活动状态的目的地。

 

 

在路由器X上的环回口关闭后，它向它的邻居路由器Y发送了一个查询包。注意查询的源是Local。“Remaining replies”中的小写字母r表示它期望从10.0.12.2（Y）上收到回复但还没收到。直到SIA-Query发送之前，sh ip eigrp topology 和 sh ip eigrp topology active 的输出完全一样。加上关键字 active 自动限制仅输出活跃状态条目。

 

 

在路由器Y上，使用后继源的查询源汇报的路由。这里在“Remaining replies”那里也有小r标志。表示期望从Z收到回复，但还没收到。由于Y和Z之间的ACL，此回复永远不会到达。条目标题中的“Q”标志表示已经为这条路由发送了查询，但尚未确认（也卡在了ACL上）。

 

 

在活动计时器过去一半以后，X和Y都将试着找出他们尚未回应的邻居是否仍在处理查询。所以它X和Y向没有回复的邻居发送SIA-Query

 

X上的“retries（1）”表示已经向Y发送了一个SIA-Query，并收到了回复。这在很多地方都可见：作为一个收到SIA-Query 回复的结果，Infinity/Infinity via 10.0.12.2的拓扑表条目被添加到 show ip eigrp active 的输出中。并且这个条目的小r标志表示仍然期望收到规律的回复，没有“s”标志表示收到SIA-Query回复。和后边的Y上的输出比较一下。

 

 

在Y上，也可见向Z发送了一个SIA查询。然而这个SIA查询没有回复。sh ip eigrp topology 的输出中，Z被标记为 SIA-Stuck。在sh ip eigrp topology active 的输出中，Z的拓扑表条目表示不仅期望一个回复（“r”），还期望一个还没收到的SIA-Query回复（“s”）。“q”标志表示已经发送了一个SIA-Query但还没收到ACK（因为ACL）。

 

最后，在下一个一半的活动计时器间隔之后还没收到SIA回复，Y决定断开和Z的邻接关系。

 

 

有些资料说正是上面这种情况才会导致路由进人SIA状态,并且它们认为这是个死局。路由器将一个目的地置为活动状态,表示它还没有完成自已的弥散计算,还不能发送响应包,这会导致两台或更多台路由器相互等待,无法从对方那里收到响应包。这是对实际情况极大的误解,这种情况并不会导致路由进人SIA状态。回想一下,当路由器将一个目的地置为活动状态后,它会发送查询包,并在其中表明拓扑变化后,自已去往目的地的当前距离,而正是这个网络变化导致路由转换为活动状态。如果在活动状态期间,路由器 收到了另一个针对该目的地的查询包,它会马上回复一个响应包,并在其中指明自已去往 目的地的距离,这与它在自已的查询包中通告的距离相同。换旬话说,路由器只是再次重 申了一遍它早已在自已的查询包中通告过的距离。并没有类似死局的情况产生。 

 

根据上图的描述,在R2和R3向对方发送了查询包(查询的是已经处于活动状 态的路由)后,它们会马上再向对方发送响应包,并在其中通告自已去往目的地的当 前距离,这个距离它们已经在各自的查询包中通告过了,也就是无穷大。在这之后, R2和R3收到了各自等待的响应包,这时它们可以完成各自的弥散计算,计算结果是 它们都没有去往该目的地的备份路径,因此它们会在向Rl发送的响应包中,表明自 已去往目的地的距离是无穷大,这样就完全终结了弥散计算。