RIP定时器研究2

1、各位 我来说说 RIP 几大定时器之我见更新30 失效定时180 抑制180 刷新240 可以用上图来说明我理解的过程 我们来说常规的：周期更新 好理解 30S 定期发送全部的路由更新 是站在发送方这边来看的 当然有水平分割的存在和network没有的缘故不一定是定期发送全部的路由再提下这个30S往往并不绝对 其实是25S-30S 失效定时器 也好理解的吧 倒过来想 我的邻居周期性30S给我发路由更新 意味着我应当每隔30S就会收一次 如果 我180S都没有收到更新就失效了 这个就是失效定时器 可以看出它的启点 就是我收到定

2、期路由信息 就开始计时。 其实 它是站在 收这边的角度来看的 而且是针对路由条目的失效后 怎么样呢 他会标记这个路由 可能down了(但查看路由表时还存在这条路由只不过已被标记为可能Down) 与此同时 抑制定时器从 结束的哪个时刻后立即开始计时 讲到这里 我不能说这是抑制定时器启动的唯一理由因为我还没有对此做唯一性论证当然也存在另种激发抑制定时器开始的可能与条件吧 继续吧 资料和show 来看都说这个是180S 先把这个提这里了 我们又来看刷新计时器 它与失效定时器一样 站在收这边的角度 而且也同失效定时器一起计时的 也针对具体路由条目 240S删除没有收到的路由更新的这条路由表项 这个是法

3、则死的 有种说法叫 我一旦收到 我本来从你处知道的路由你却又给我传来从你处不能去了的路由信息（不能理解为失效而是在周期内也许应当说在失效定时期内明明白收到你发我的跳的路由信息的这种情况） 会立即启动抑制计时器 另外一种说法是 无效计时器到时后 （是失去丢失没有收到更新的情况）才 立即的启动了 抑制定时器 哪么以上两种说法有问题吗是其中之一是正确的 还是两种都对或是都错呢 补充一点 这两种有本质不同啊 前面一种是 你明确给我讲你去不了目的 第二种呢 是我没有收到你发的周期更新，我自已判断认为不可达 随后我还要把我的认为不可达 传递给我所有的邻居=抑制定时器 反正是要等 等什么 等我失去的哪个路由

4、（超过无效计时器规定时间被标为可能down） 能恢复(在没有超出抑制定时器规定的时间收到失去的路由)I 。如果能恢复 哪么路由器从新标记被可能down的路由为可用可达 并将除周期更新的其它个计时器重置； 如收到更好的路由(这里仅指路由相同但度理值更优)我加入路由表也将除周期更新的其它个计时器重置这期间 有如果有更差的路由进来的话 我在抑制定时器规定的时间内 则 忽略这个路由更新 这是其中说法之一 这个工作机制前提是 我失去路由的前提哪么另种呢 以前这个路由是你给我的 现在你又明明白白传过来一个16跳 说不能通过你到达了 我也立即的启动抑制的定时器这是另外一种说法随后的法则和前面一样 哪么以上两

5、种说法有问题吗是其中之一是正确的 还是两种都对呢还是有特定的情形下后者对呢 以上为从各种资料上所述的情形。说到这里大家不知发现问题了没有 有这60S 他属于刷新计时器 又属 抑制定时器 哪么这个60S 到底是拒绝接受呢 还是要接受呢 应当要吧 因为不是有前面说的逻辑判断法则的呀又如过完这抑制定时器并没有完都还有120可是前面提到刷新计时器到期了(即失效定时器到期并标为可能down的路由又过了，)它会无条件的删除这个路由，而抑制定时器并没有完都还有120，是不是同样会被抑制呢注：flush计时器是和invalid计时器一起开始计时的 所以总共240秒一到 本路由就会被清除掉,而不是等到 hold

6、down的180秒走完 总共要等invaild+holddown=180+180=360, 实际的时间最高就是240秒左右(有一定的偏差） 所以240S删除没有收到的路由更新的这条路由表项 这个是法则死的 综上是不是有这些问题和矛盾啊 不知这些问题在你的心中有怎样的判断?我想我们首先要解决的是什么时候启动抑制的定时器验证两种启动抑制定时器激活条件也就是说看前面说的两种情形是都对还是都不对还是其中之一对把这个问题 搞清了 再来看抑制定时器内收到路由（不同度量值）的后继动作和没有收到的后继动作 是不是如理论说讲的哪样一致的须要设计好几个实验来观察 实验 由易到难 逐步深入 依上图 运行 全部运行

7、rip v1 在 R1上 建lo0 100.100.100.1/24并参与rip； 收敛完毕后 打开 R2 R3 R4 的 调试信息 debug ip routing 及 debug ip rip 将 R1 的 F0/0中设为被动接口 在300S内 观察 R2 R3 R4的 调 试信 息 此项实验来观察 丢失路由（也就是说失效定时器到期都还没有收到的这种情形）我先来分析一下 或者说 对实验结果的一个预测 当正常收敛完毕后 ，R1会以30S周期的将100.0.0.0的更新发给R2 且周期更新中也只会包含这一条路由对外发布并且通过R1的F0/0 这个大伙经过的学习对这个都应当认同的吧；当 R1 的

8、 F0/0设为被动接口后，R2将收不到此条路由信息了(来模拟丢失传来的100.0.0.0) 如果到了180S 还是没有收到 R2路由器在自己的路由表中把该路由条目设置为可能丢失(possibly down)；随后R2将把该路由条目设置为不可达(Metric为16)通过自身参与rip的各个接口更新出去这是个毒化路由。这里有个问题当R2在失效定时期180S内 R2的路由表依然有正常的 100.0.0.0这个路由表项 会按30S一个周期给R3发的 ，所以 R2 就算在无效计时期内没有收到 这个更新 但它并不影响我的正常工作。只有当过了无效定时期时 路由器才会把该路由条目设置为可能丢失(possibl

9、y down)；且开始了抑制计时器的计时并把该路由条目设置为不可达(Metric为16)通过自身参与rip的各个接口更新出去。接下来R3收到这个16条的毒化路由 会怎么办呢 R4又是怎么办的呢 随着时间的流失R2收不到100.0.0.0的路由又过了60S 到达了 240S 了 这下刷新计进器到期了 我R2 肯定会从路由表中删了关于100.0.0.0的路由表项 和我分析的结果会一样吗 我们通过实验来看吧我们看R2的调试信息：R2#sh ip rip da12.0.0.0/8 auto-summary12.12.12.0/24 directly connected, FastEthernet0/0

10、23.0.0.0/8 auto-summary23.23.23.0/24 directly connected, FastEthernet2/034.0.0.0/8 auto-summary34.0.0.0/8 1 via 23.23.23.3, 00:00:00, FastEthernet2/0100.0.0.0/8 auto-summary100.0.0.0/81 via 12.12.12.1, 00:02:59, FastEthernet0/0 马上R2就到180 S 没有收到 此条的路由信息了 （我在2分多钟前将R1的F0/0设成了被动接口的原因）R2#sh ip rip da12.0

11、.0.0/8 auto-summary12.12.12.0/24 directly connected, FastEthernet0/023.0.0.0/8 auto-summary23.23.23.0/24 directly connected, FastEthernet2/034.0.0.0/8 auto-summary34.0.0.0/8 1 via 23.23.23.3, 00:00:08, FastEthernet2/0100.0.0.0/8 auto-summary100.0.0.0/8 1 via 12.12.12.1, 00:03:07, FastEthernet0/0 已经过

12、了180S 可R2 还没有对此路由条目有反应 这也说明 180S不绝对 有时是左右 有小的偏差R2#*Mar 1 00:21:16.863: RT: delete route to 100.0.0.0 via 12.12.12.1, rip metric 120/1 有反应了 *Mar 1 00:21:16.867: RT: SET_LAST_RDB for 100.0.0.0/8 设置此条路由在 rip 数据库中 为丢失 可能down状态 这时查看路由表肯定还会有显示这个路由不过表明了是可能down OLD rdb: via 11.13.11.13*Mar 1 00:21:16.871: R

13、T: no routes to 100.0.0.0, entering holddown 随后立即进入 抑制状态 并开始抑制计时器的计时 从无效到期到启动抑制计时仅隔ms（毫秒）*Mar 1 00:21:16.875: RT: NET-RED 100.0.0.0/8R2#*Mar 1 00:21:18.879: RIP: sending v1 flash update to 255.255.255.255 via FastEthernet0/0 (12.12.12.2) 并将该路由条目设置为不可达(Metric为16)通过自身参与rip的各个接口更新出去*Mar 1 00:21:18.879:

14、 RIP: build flash update entries*Mar 1 00:21:18.879: network 100.0.0.0 metric 16 *Mar 1 00:21:18.879: RIP: sending v1 flash update to 255.255.255.255 via FastEthernet2/0 (23.23.23.2) 并将该路由条目设置为不可达(Metric为16)通过自身参与rip的各个接口更新出去*Mar 1 00:21:18.879: RIP: build flash update entries*Mar 1 00:21:18.879: ne

15、twork 100.0.0.0 metric 16 此处的确看得出是个毒化路由 特征是 从我各个接口传出 传出去后 R3肯定会收到这个毒化路由 R3 会怎么 做呢 我应当把R3 的调试信息 部份插入到这里来看 R3#*Mar 1 00:21:10.591: RIP: received v1 update from 23.23.23.2 on FastEthernet2/0 它从R2收到了关于100.0.0.0的毒化路由*Mar 1 00:21:10.595: 100.0.0.0 in 16 hops (inaccessible)*Mar 1 00:21:10.599: RT: del 100.

16、0.0.0 via 23.23.23.2, rip metric 120/2 马上就将这个路由从我的路由表中删除了*Mar 1 00:21:10.603: RT: delete network route to 100.0.0.0*Mar 1 00:21:10.603: RT: NET-RED 100.0.0.0/8R3#*Mar 1 00:21:12.607: RIP: sending v1 flash update to 255.255.255.255 via FastEthernet2/0 (23.23.23.3) 而且 也快速的转发了 这个毒化路由 发给了R4*Mar 1 00:21:

17、12.611: RIP: build flash update entries*Mar 1 00:21:12.611: network 100.0.0.0 metric 16*Mar 1 00:21:12.615: RIP: sending v1 flash update to 255.255.255.255 via FastEthernet0/0 (34.34.34.3) 而且也又把这个 发回给了R2 *Mar 1 00:21:12.619: RIP: build flash update entries*Mar 1 00:21:12.619: network 100.0.0.0 metri

18、c 16R3#*Mar 1 00:21:14.743: RIP: received v1 update from 34.34.34.4 on FastEthernet0/0 收到R4发回来的毒化路由 证明R4回发了这个毒化路由*Mar 1 00:21:14.747: 100.0.0.0 in 16 hops (inaccessible)R3#*Mar 1 00:21:17.691: RIP: received v1 update from 34.34.34.4 on FastEthernet0/0 继续收到收到R4发回来的毒化路由 证明R4回发了这个毒化路由*Mar 1 00:21:17.69

19、5: 100.0.0.0 in 16 hops (inaccessible)*Mar 1 00:21:18.295: RIP: received v1 update from 23.23.23.2 on FastEthernet2/0 续续收到R2发来的毒化路由*Mar 1 00:21:18.295: 12.0.0.0 in 1 hops*Mar 1 00:21:18.295: 100.0.0.0 in 16 hops (inaccessible)R3#*Mar 1 00:21:27.807: RIP: sending v1 update to 255.255.255.255 via Fast

20、Ethernet2/0 (23.23.23.3) 我又继续发给R2*Mar 1 00:21:27.811: RIP: build update entries*Mar 1 00:21:27.811: network 34.0.0.0 metric 1*Mar 1 00:21:27.811: network 100.0.0.0 metric 16R3#*Mar 1 00:21:36.495: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (34.34.34.3) 我又继续发给R4*Mar 1 00:21:36.499:

21、 RIP: build update entries*Mar 1 00:21:36.499: network 12.0.0.0 metric 2*Mar 1 00:21:36.503: network 23.0.0.0 metric 1*Mar 1 00:21:36.503: network 100.0.0.0 metric 16R3#*Mar 1 00:21:46.051: RIP: received v1 update from 23.23.23.2 on FastEthernet2/0 还在接受R2发来的毒化*Mar 1 00:21:46.055: 12.0.0.0 in 1 hops*

22、Mar 1 00:21:46.059: 100.0.0.0 in 16 hops (inaccessible)*Mar 1 00:21:46.395: RIP: received v1 update from 34.34.34.4 on FastEthernet0/0 接受R4发来的毒化*Mar 1 00:21:46.399: 100.0.0.0 in 16 hops (inaccessible)R3#*Mar 1 00:21:54.011: RIP: sending v1 update to 255.255.255.255 via FastEthernet2/0 (23.23.23.3) 又

23、发给R2*Mar 1 00:21:54.015: RIP: build update entries*Mar 1 00:21:54.015: network 34.0.0.0 metric 1*Mar 1 00:21:54.019: network 100.0.0.0 metric 16R3#*Mar 1 00:22:04.171: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (34.34.34.3) 又发给R4 *Mar 1 00:22:04.175: RIP: build update entries*Mar

24、1 00:22:04.175: network 12.0.0.0 metric 2*Mar 1 00:22:04.175: network 23.0.0.0 metric 1*Mar 1 00:22:04.175: network 100.0.0.0 metric 16R3#*Mar 1 00:22:14.959: RIP: received v1 update from 23.23.23.2 on FastEthernet2/0*Mar 1 00:22:14.963: 12.0.0.0 in 1 hopsR3#*Mar 1 00:22:21.035: RIP: sending v1 upda

25、te to 255.255.255.255 via FastEthernet2/0 (23.23.23.3)*Mar 1 00:22:21.039: RIP: build update entries*Mar 1 00:22:21.039: network 34.0.0.0 metric 1R3#*Mar 1 00:22:33.355: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (34.34.34.3)*Mar 1 00:22:33.359: RIP: build update entries*Mar 1 00:

26、22:33.359: network 12.0.0.0 metric 2*Mar 1 00:22:33.363: network 23.0.0.0 metric 1R3#no debug all 以上R3的逻辑是什么呢 我一收到 16跳的毒化路由 我立即就从路由表中删除了这条路由项 并且也向我的所有参与rip接口 发出毒化路由 且 可以看出毒化路由不受 周期更新 与 水平分割的影响= 看完插入的R3 信息 再来插入 R4的调试信自息吧 请看 R4#*Mar 1 00:21:26.551: RIP: received v1 update from 34.34.34.3 on FastEthern

27、et0/0 我收到了R3发来的 毒化路由*Mar 1 00:21:26.555: 100.0.0.0 in 16 hops (inaccessible)*Mar 1 00:21:26.559: RT: del 100.0.0.0 via 34.34.34.3, rip metric 120/3 R4一收到R3的这个毒化的路由 我立即的 从我路由表中删除了此路由表项*Mar 1 00:21:26.563: RT: delete network route to 100.0.0.0*Mar 1 00:21:26.563: RT: NET-RED 100.0.0.0/8R4#*Mar 1 00:21

28、:28.567: RIP: sending v1 flash update to 255.255.255.255 via FastEthernet0/0 (34.34.34.4) 并且很快将这个 毒化路由从我参与rip的所有接口 发出 毒化的路由包括又发给R3*Mar 1 00:21:28.571: RIP: build flash update entries*Mar 1 00:21:28.571: network 100.0.0.0 metric 16R4#*Mar 1 00:21:31.603: RIP: sending v1 update to 255.255.255.255 via

29、FastEthernet0/0 (34.34.34.4)*Mar 1 00:21:31.603: RIP: build update entries*Mar 1 00:21:31.603: network 100.0.0.0 metric 16 通过这个口还在 发 R4#*Mar 1 00:21:50.419: RIP: received v1 update from 34.34.34.3 on FastEthernet0/0*Mar 1 00:21:50.423: 12.0.0.0 in 2 hops*Mar 1 00:21:50.427: 23.0.0.0 in 1 hops*Mar 1

30、00:21:50.427: 100.0.0.0 in 16 hops (inaccessible) 又从R3处收到R4#*Mar 1 00:22:00.283: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (34.34.34.4)*Mar 1 00:22:00.287: RIP: build update entries*Mar 1 00:22:00.291: network 100.0.0.0 metric 16 又通过这个口发R4#sh ip routeGateway of last resort is not

31、 set34.0.0.0/24 is subnetted, 1 subnetsC 34.34.34.0 is directly connected, FastEthernet0/0R 23.0.0.0/8 120/1 via 34.34.34.3, 00:00:16, FastEthernet0/0R 12.0.0.0/8 120/2 via 34.34.34.3, 00:00:16, FastEthernet0/0R4#*Mar 1 00:22:18.107: RIP: received v1 update from 34.34.34.3 on FastEthernet0/0*Mar 1 0

32、0:22:18.111: 12.0.0.0 in 2 hops*Mar 1 00:22:18.115: 23.0.0.0 in 1 hops*Mar 1 00:22:18.115: 100.0.0.0 in 16 hops (inaccessible) 还在从R3收到 毒化的不可达的路由信息R4#*Mar 1 00:22:27.871: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (34.34.34.4)*Mar 1 00:22:27.871: RIP: build update entries - suppres

33、sing null updateR4#*Mar 1 00:22:47.279: RIP: received v1 update from 34.34.34.3 on FastEthernet0/0*Mar 1 00:22:47.283: 12.0.0.0 in 2 hops*Mar 1 00:22:47.287: 23.0.0.0 in 1 hopsR4#*Mar 1 00:22:55.039: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (34.34.34.4)*Mar 1 00:22:55.043: RIP:

34、build update entries - suppressing null updateR4#no debug allAll possible debugging has been turned offR4# 上面收发是能和R3对应得上的 以上R4又是怎么样的逻辑呢 其实和R3的一模一样 我一收到 16跳的毒化路由 我立即就从路由表中删除了这条路由项 并且也像我的所有参与rip接口 发出毒化路由 且 可以看出毒化路由不受 周期更新 与 水平分割的影响=我们再次回到 R2上来解读报调试信息吧R2#*Mar 1 00:21:20.911: RIP: received v1 update fro

35、m 23.23.23.3 on FastEthernet2/0 *Mar 1 00:21:20.915: 100.0.0.0 in 16 hops (inaccessible) R2 从R3 接收到了 关于这条的毒化路由 并且是我始发的 确又传回给我了 再次证明他不受水平分割的影响*Mar 1 00:21:20.919: RT: 100.0.0.0 came out of holddown 这条说明我收到了一条关于100.0.0.0的路由 我就从 holdown状态中走出 或出来 =疑问：难到只要收到同样的路由就结束了抑制状态吗？还是只有在我这样的拓朴与编址设计中才会是这样的呢 R2#*Mar

36、 1 00:21:26.555: RIP: sending v1 update to 255.255.255.255 via FastEthernet2/0 (23.23.23.2)*Mar 1 00:21:26.555: RIP: build update entries*Mar 1 00:21:26.555: network 12.0.0.0 metric 1*Mar 1 00:21:26.555: network 100.0.0.0 metric 16 继续向外发 毒化路由R2#*Mar 1 00:21:31.603: RIP: sending v1 update to 255.255.

37、255.255 via FastEthernet0/0 (12.12.12.2)*Mar 1 00:21:31.607: RIP: build update entries*Mar 1 00:21:31.607: network 23.0.0.0 metric 1*Mar 1 00:21:31.607: network 34.0.0.0 metric 2*Mar 1 00:21:31.607: network 100.0.0.0 metric 16 继续向外发 毒化路由R2#*Mar 1 00:21:36.123: RIP: received v1 update from 23.23.23.3

38、 on FastEthernet2/0*Mar 1 00:21:36.127: 34.0.0.0 in 1 hops*Mar 1 00:21:36.131: 100.0.0.0 in 16 hops (inaccessible) 继续收到 毒化路由R2#*Mar 1 00:21:54.339: RIP: sending v1 update to 255.255.255.255 via FastEthernet2/0 (23.23.23.2)*Mar 1 00:21:54.343: RIP: build update entries*Mar 1 00:21:54.343: network 12.

39、0.0.0 metric 1*Mar 1 00:21:54.343: network 100.0.0.0 metric 16 继续向外发 毒化路由R2#*Mar 1 00:22:00.907: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (12.12.12.2)*Mar 1 00:22:00.911: RIP: build update entries*Mar 1 00:22:00.911: network 23.0.0.0 metric 1*Mar 1 00:22:00.915: network 34.0.0.0

40、 metric 2*Mar 1 00:22:00.915: network 100.0.0.0 metric 16 继续向外发 毒化路由R2#*Mar 1 00:22:02.347: RIP: received v1 update from 23.23.23.3 on FastEthernet2/0*Mar 1 00:22:02.351: 34.0.0.0 in 1 hops*Mar 1 00:22:02.355: 100.0.0.0 in 16 hops (inaccessible) 继续收到 毒化路由R2#sh ip routeGateway of last resort is not s

41、etR 34.0.0.0/8 120/1 via 23.23.23.3, 00:00:06, FastEthernet2/0R 100.0.0.0/8 is possibly down, routing via 12.12.12.1, FastEthernet0/0 23.0.0.0/24 is subnetted, 1 subnetsC 23.23.23.0 is directly connected, FastEthernet2/0 12.0.0.0/24 is subnetted, 1 subnetsC 12.12.12.0 is directly connected, FastEthe

42、rnet0/0R2#*Mar 1 00:22:16.879: RT: delete network route to 100.0.0.0 我将最前面的 *Mar 1 00:21:16.871: RT: no routes to 100.0.0.0, entering holddown复制到这里来看 好做时间对比 从失效定时器到期并且开始抑制定时器计时 后60S(本次实验刚好是60S) 到了 240S也就是刷新计时器到点 R2 无条件的 从路由表删除了这条路由表项 这里时间还比较准 *Mar 1 00:22:16.883: RT: NET-RED 100.0.0.0/8R2#sh ip rout

43、eGateway of last resort is not setR 34.0.0.0/8 120/1 via 23.23.23.3, 00:00:24, FastEthernet2/0 23.0.0.0/24 is subnetted, 1 subnetsC 23.23.23.0 is directly connected, FastEthernet2/0 12.0.0.0/24 is subnetted, 1 subnetsC 12.12.12.0 is directly connected, FastEthernet0/0 从这里看已经没有了100.0.0.0的路由了240都没有收到的

44、话我就彻底的删了他R2#*Mar 1 00:22:28.335: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (12.12.12.2)*Mar 1 00:22:28.339: RIP: build update entries*Mar 1 00:22:28.339: network 23.0.0.0 metric 1*Mar 1 00:22:28.343: network 34.0.0.0 metric 2R2#*Mar 1 00:22:29.351: RIP: received v1 update from 23.23.23.3 on FastEthernet2/0*Mar 1 00:22:29.355: 34.0.0.0 in 1 hopsR2#no debug all好至此我们结束了 这个实验 好像一切都如书中和资料上讲的 但有个非常值得注意的调试信自息 我复制过来 请看下面： 这个很关键啊 这次 提出来让大家 有个印像 知道有这么回事 就行 好这个实验 完成 。 我们梳理几个关键点：当不能定期30从先前的“源”收到100.0.0.0的路由通