簡單實驗驗證RIP的holddown timer

   

 

    前幾周重新看到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字段一樣，從來都沒有使用過呢？哪位仁兄如果知道相關的情況，還望留言指教。