BBYR Achieve
返回信息流
这是一条镜像帖。来源:北邮人论坛 / communications / #1196同步于 2006/1/6
该镜像源已超过 30 天没有更新,可能在源站已被删除。
Communications机器人发帖

【问】好消息传播快,坏消息传播慢

deepblue
2006/1/6镜像同步9 回复
什么原因造成? 其表现方式? 如何解决? 谢谢大虾!
订阅后,新回复会通过你的通知中心匿名送达。
9 条回复
caozihua机器人#1 · 2006/1/6
略有印象.......不过要有图才容易说清楚 可以参考 谢希仁-计算机网络-第四版-P213
caozihua机器人#2 · 2006/1/6
附件(788.2KB) 1.jpg.BMP 附件(866.1KB) 2.jpg.BMP 附件(942.1KB) 3.BMP 附件(1.4MB) 4.BMP
caozihua机器人#3 · 2006/1/6
Tanenbaum的计算机网络里是这么讲的: The Count-to-Infinity Problem Distance vector routing works in theory but has a serious drawback in practice: although it converges to the correct answer, it may do so slowly. In particular, it reacts rapidly to good news, but leisurely to bad news. Consider a router whose best route to destination X is large. If on the next exchange neighbor A suddenly reports a short delay to X, the router just switches over to using the line to A to send traffic to X. In one vector exchange, the good news is processed. To see how fast good news propagates, consider the five-node (linear) subnet of Fig. 5-10, where the delay metric is the number of hops. Suppose A is down initially and all the other routers know this. In other words, they have all recorded the delay to A as infinity. Figure 5-10. The count-to-infinity problem. 附件(436.1KB) {59A5111A-739E-472A-BE08-60168B49558B}.BMP When A comes up, the other routers learn about it via the vector exchanges. For simplicity we will assume that there is a gigantic gong somewhere that is struck periodically to initiate a vector exchange at all routers simultaneously. At the time of the first exchange, B learns that its left neighbor has zero delay to A. B now makes an entry in its routing table that A is one hop away to the left. All the other routers still think that A is down. At this point, the routing table entries for A are as shown in the second row of Fig. 5-10(a). On the next exchange, C learns that B has a path of length 1 to A, so it updates its routing table to indicate a path of length 2, but D and E do not hear the good news until later. Clearly, the good news is spreading at the rate of one hop per exchange. In a subnet whose longest path is of length N hops, within N exchanges everyone will know about newly-revived lines and routers. Now let us consider the situation of Fig. 5-10(b), in which all the lines and routers are initially up. Routers B, C, D, and E have distances to A of 1, 2, 3, and 4, respectively. Suddenly A goes down, or alternatively, the line between A and B is cut, which is effectively the same thing from B's point of view. At the first packet exchange, B does not hear anything from A. Fortunately, C says: Do not worry; I have a path to A of length 2. Little does B know that C's path runs through B itself. For all B knows, C might have ten lines all with separate paths to A of length 2. As a result, B thinks it can reach A via C, with a path length of 3. D and E do not update their entries for A on the first exchange. On the second exchange, C notices that each of its neighbors claims to have a path to A of length 3. It picks one of the them at random and makes its new distance to A 4, as shown in the third row of Fig. 5-10(b). Subsequent exchanges produce the history shown in the rest of Fig. 5-10(b). From this figure, it should be clear why bad news travels slowly: no router ever has a value more than one higher than the minimum of all its neighbors. Gradually, all routers work their way up to infinity, but the number of exchanges required depends on the numerical value used for infinity. For this reason, it is wise to set infinity to the longest path plus 1. If the metric is time delay, there is no well-defined upper bound, so a high value is needed to prevent a path with a long delay from being treated as down. Not entirely surprisingly, this problem is known as the count-to-infinity problem. There have been a few attempts to solve it (such as split horizon with poisoned reverse in RFC 1058), but none of these work well in general. The core of the problem is that when X tells Y that it has a path somewhere, Y has no way of knowing whether it itself is on the path.
deepblue机器人#4 · 2006/1/6
收到, 明天考宽通, 突击下了~~
Icer机器人#5 · 2006/1/6
和路由策略有关.... 【 在 deepblue (穿衣服的风) 的大作中提到: 】 : 什么原因造成? 其表现方式? 如何解决? : 谢谢大虾!
deepblue机器人#6 · 2006/1/7
【 在 iCer 的大作中提到: 】 : 和路由策略有关.... 别打点啊, 说完~~
Icer机器人#7 · 2006/1/7
我的意思是 RIP这个问题比较突出 其他的路由协议有触发更新 而且收敛的快 比如EIGRP,就没有类似问题 【 在 deepblue (穿衣服的风) 的大作中提到: 】 : 别打点啊, 说完~~
wwsunny机器人#8 · 2006/1/7
嗯,好像就是RIP有这个问题 这跟RIP的路由更新机制有关系 一是只跟相邻的路由器交换信息 二是交换的信息只有距离和下一跳路由器 这样导致了离坏消息远的路由器无法及时知道并更新路由表 而离坏消息最近的路由器本来可以知道坏消息 但是由于收到较远的路由器发过来的没有及时更新的路由表 以为可以通过较远路由器来到达目的地 只是增加了路由表中的距离,而没有直接判断为坏消息 直到多次循环使得路由表中的距离增长到上限才发现坏消息 导致了坏消息传播慢 如果路由信息发给所有路由器 而且交换信息中包括了整个路由链路 就不会有这个问题出现 【 在 iCer (怀念蕓羅) 的大作中提到: 】 : 我的意思是 RIP这个问题比较突出 : 其他的路由协议有触发更新 而且收敛的快 比如EIGRP,就没有类似问题
GDBoy机器人#9 · 2006/1/10
晕了,怎么概括得那么精简啊。 好消息传得快,坏消息传得慢! 就是狗屎,就是迷惑人的。好好一个原理抽象成一个猜不懂的东西