前几周重新看到RIP协议的时候，发现RIP的4个计时器中的holddown timer有些问题。在RFC中，并没有关于抑制计时器的定义。这是cisco自己加到rip中的。书上一直没有明确的说明holddown timer的起点，只是说长度为180s。功能是在抑制阶段不接受也不发送所抑制的路由条目的任何信息。后来在TCP/IP路由卷一重发布部分看到RIP的holddown timer是从invalid timer超时后开始的，同时发现在失效计时器超时后路由条目进入possibilly down状态，这个状态下路由器并不接受关于该条目的任何信息。但是当flush timer结束后（invalid timer后60s）只有60s，路由信息就被删除了，并不能说明holddown的作用。于是，设计实验验证holddown timer。
实验拓扑图如下：
3台路由器启用RIPv2，将3台路由器的计时器分别设计为update 10s invalid 30s holddown 30s flush 120s
在3台路由器上开始debug ip rip，passive R1的S1/0，让R2收不到更新消息，R2路由表中1.1.1.0/24的条目经过30s后状态变成possibilly down，迅速开启R1的S1/0（no passive interface s1/0）.从debug信息可以看出来，R2收到R1发来的关于1.1.1.0/24的路由更新，但是在holddown时间并没有接受（超时计时器超时后的30s）。过了大约30s后（自己计时为32s）R2接受了该条目，此时flush timer还没有到。
以上实验可以验证holddown timer是从invalid timer超时后开始的，但默认情况下，应该只有60s，cisco却把它设为180s...
关于RIP还有一些问题，RIP的请求消息中本来应该有两种，全部路由，单条路由。但是从来没有见过请求单条路由的情况。这个是不是也和tos字段一样，从来都没有使用过呢？哪位仁兄如果知道相关的情况，还望留言指教。
本文出自 “慕枫的部落格~” 博客，谢绝转载！
简单实验验证RIP的holddown timer
社区：
这个计时器似呼并没有起作用,
没有保持,而是立马接受