RIP中4个定时器

3421

①updata timer（组播定期更新时间）：默认每30s/次，组播地址224.0.0.9
②invalid timer（失效时间）：默认是180s
③flush timer（刷新时间）：cisco默认为240s
④holddown timer（死亡时间）：默认180s


每个路由条目建立后每30s组播更新一次，并且开始180s invalid timer倒计时，如果如果这个时间内没有收到更新，则该路由条目自动变成16跳，即不可达（失效）
x.x.x.x is possibly down

flush timer计时器比invalid timer 多60s，也就是说：
如果一个路由条目180s内没收到更新那么它就失效了，updata timer这个表停了，flush timer 继续计时，如果又过了60秒都没收到更新，则路由条目从路由表中***；如果在这时间内收到更新了，则2个计时器同时被初始化。

holddown timer 这个时间一直感觉比较神奇，它是从 invalid timer 完毕之后开始计算的，在这个时间里他不接受也不发送任何关于该条目的更新信息，但是问题出来了：
180s的 invalid timer 后只有60秒时间 flush timer 就到期，但是又有180s时间是不能接收更新的，于是这个时间变得毫无意义。
后来查过一些资料后才发现，其实这个时间是cisco自己加进来的，cisco书上写的是180s，但是实验发现大概只有30s左右。主要用途是防止环路，举例如下：

(C) s2<----X---->s1 (A) s2<----->s1 (B)

路由器C的s2接口挂了，A收不到前往C的路由更新，该路由条目180s后失效，但这时候B路由定期组播了先前从A那里学来的前往C的条目，若A接受了，则A以为可以从B到达C，于是环路就形成了。
所以cisco设定了这个holddown timer。该路由条目180s后失效后进入holddown timer，B关于到达C的路由条目更新被无视，差不多30s左右的时间里，B路由表中到C的路由条目invalid timer也到期了，进入不可用状态，就不会向A发送更新。
这个holddown timer就是用来缓冲邻居路由器进入invalid的时间上的不同，防止环回。

以下是对于holddown timer的进一步解释：
抑制定时器，作用是在路由条目不可达后一定时间内不允许被响应（Response）报文更新。
它的思想是保证每台路由器都收到路由不可达信息之前，不可达路由不会被收到的响应（Response）报文更新。因为收到的响应（Response）报文中该路由条目的信息有可能就是自己原先通告出去的。