RIP 的防環機制共有6種：
1.最大跳數
2.水平分割
3.毒化路由
4.毒性逆轉
5.hold-down計時器
6.觸發更新
聯想：定時更新和觸發更新的區別：
· 定時更新：運行如RIP，IGRP等距離矢量協議的路由器以一定的時間間隔廣播路由表的全部內容。
RIP缺省情況下每隔30s向每個活躍接口廣播所有路由。IGRP的缺省更新時間間隔是90s。
觸發更新：更新通過在網絡發生變化時為等待到定時更新的時間點就立即發送更新，從
而消除了定時更新帶來的收斂延遲，快速更新發生在網絡的結點和結點之間，減少了整
個網絡的收斂時間。
以下針對每種更新方式，以實驗的方式進行驗證：
l 最大跳數演示試驗：
R1上有一個環回口地址1.1.1.1/24位，全網起RIP V2協議，演示醉倒跳數的試驗。
R2 R3 #show ip route rip
正常情況下R2的下一跳是R1的串口地址，R3的下一跳是R1的以太口地址。
第一步：被動接口R1的以太網口R1(config-router)#pass fa0/0
大約4分鍾后，R3上看到的1.1.1.0/24的下一跳是R2過來的。
第二步：把R1的s1/1的接口也被動掉，且斷開lookback0接口。且打開個各個路由器的
debug ip rip
R1(config)#router rip
R1(config-router)#passive-interface s1/1
R1(config)#int loopback 0
R1(config-if)#shutdown
第三步：直到R1收到1.1.1.0的下一跳是R2時，打開s1/1的被動接口。
R1(config-router)#do show ip route rip
1.0.0.0/24 is subnetted, 1 subnets
R 1.1.1.0 [120/3] via 172.16.1.3, 00:00:02, FastEthernet0/0
通過上面的一系列設置，1.0.0.0這個網絡已經在拓撲上出現R1-R2-R3-R1這樣的路由
環。下面我們看看上面的debug信息：
此時R1,R2,R3的RIP數據庫都呈現：
R2#show ip rip database
1.0.0.0/8 is possibly down
1.1.1.0/24 is possibly down
10.0.0.0/8 auto-summary
10.1.12.0/24 directly connected, Serial1/0
10.1.23.0/24 directly connected, Serial1/1
10.1.34.0/26 is possibly down
10.1.45.1/32 is possibly down
172.16.0.0/16 auto-summary
172.16.1.0/24
[1] via 10.1.12.1, 00:00:19, Serial1/0
[1] via 10.1.23.3, 00:00:11, Serial1/1
注意：如果收不到這個路由，他立刻會在路由表中清除這條路由，但是仍然會在RIP的
數據庫中保留60s時間，60s過后，在RIP的數據庫中也將被清除。
l 水平分割實驗：
水平分割規則是：從一個接口學習到的路由不會再廣播回該接口。
此處有一點問題：
如果同一個接口從不同地方收到了同一條路由信息，但是一個是metric=1，一個
metric=2
它會接收這條路由，並且從同一個接口發送出去。
上面的說法應該是：從一個接口學習到的最優路由不會在發送回給接口。
暫時先斷開R1與R3之間的鏈路：此時R2，R3的目的網段1.1.1.0/24的路由條目如下：
R2#show ip rout rip
1.0.0.0/24 is subnetted, 1 subnets
R 1.1.1.0 [120/1] via 10.1.12.1, 00:00:13, Serial1/0
10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
R 10.1.45.1/32 [120/1] via 10.1.12.1, 00:00:13, Serial1/0
R 10.1.34.0/26 [120/1] via 10.1.12.1, 00:00:13, Serial1/0
R3#sho ip route rip
1.0.0.0/24 is subnetted, 1 subnets
R 1.1.1.0 [120/2] via 10.1.23.2, 00:00:08, Serial1/0
10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
R 10.1.12.0/24 [120/1] via 10.1.23.2, 00:00:09, Serial1/0
R 10.1.45.1/32 [120/2] via 10.1.23.2, 00:00:09, Serial1/0
R 10.1.34.0/26 [120/2] via 10.1.23.2, 00:00:09, Serial1/0
R2#
*Jun 28 20:46:06.975: RIP: sending v2 update to 224.0.0.9 via Serial1/0
(10.1.12.2)
*Jun 28 20:46:06.975: RIP: build update entries
*Jun 28 20:46:06.979: 10.1.23.0/24 via 0.0.0.0, metric 1, tag 0//向R1發送
更新時沒有包括1.1.1.0/24的更新
R2#
*Jun 28 20:46:30.151: RIP: sending v2 update to 224.0.0.9 via Serial1/1
(10.1.23.2)
*Jun 28 20:46:30.151: RIP: build update entries
*Jun 28 20:46:30.155: 1.1.1.0/24 via 0.0.0.0, metric 2, tag 0//向R3發送更
新時就帶有1.1.1.0/24的路由條目
*Jun 28 20:46:30.155: 10.1.12.0/24 via 0.0.0.0, metric 1, tag 0
*Jun 28 20:46:30.159: 10.1.34.0/26 via 0.0.0.0, metric 2, tag 0
*Jun 28 20:46:30.159: 10.1.45.1/32 via 0.0.0.0, metric 2, tag 0
從上面的debug信息可以看出：
從debug信息可以看到，R2從s1/0接收來自R1的1.0.0.0/8路由條目，再從s1/0發送更新
時，只有10.1.23.0的網絡，並沒有包括了1.0.0.0的網絡，但從s1/1發送到R3的更新時，
卻包括了1.0.0.0的網絡，這就是說水平分割已經起作用了。
現在打開R1,R2的水平分割原則：
R1(config-if)#no ip split-horizon
R2(config-if)#no ip split-horizon
*Jun 28 20:53:45.882: RIP: sending v2 update to 224.0.0.9 via Serial1/0
(10.1.12.2)
*Jun 28 20:53:45.882: RIP: build update entries
*Jun 28 20:53:45.886: 1.1.1.0/24 via 10.1.12.1, metric 2, tag 0
*Jun 28 20:53:45.886: 10.1.12.0/24 via 0.0.0.0, metric 1, tag 0
*Jun 28 20:53:45.890: 10.1.23.0/24 via 0.0.0.0, metric 1, tag 0
*Jun 28 20:53:45.890: 10.1.34.0/26 via 10.1.12.1, metric 2, tag 0
*Jun 28 20:53:45.890: 10.1.45.1/32 via 10.1.12.1, metric 2, tag 0
*Jun 28 20:54:03.482: RIP: sending v2 update to 224.0.0.9 via Serial1/1
(10.1.23.2)
*Jun 28 20:54:03.482: RIP: build update entries
*Jun 28 20:54:03.486: 1.1.1.0/24 via 0.0.0.0, metric 2, tag 0
*Jun 28 20:54:03.486: 10.1.12.0/24 via 0.0.0.0, metric 1, tag 0
*Jun 28 20:54:03.490: 10.1.34.0/26 via 0.0.0.0, metric 2, tag 0
*Jun 28 20:54:03.490: 10.1.45.1/32 via 0.0.0.0, metric 2, tag 0
從R1收到的更新，再次的發回給R1。
從debug信息可以看到，關閉水平分割之后，R2從S1/0接收來自R1的1.0.0.0網絡，又從
S1/0發送回給R1。
為了達到效果，先被動掉R1的s1/1口，接口關閉環回口1.1.1.1/24，然后取消R1的被動
接口S1/1。
R2#
*Jun 28 20:57:55.694: RIP: sending v2 update to 224.0.0.9 via Serial1/1
(10.1.23.2)
*Jun 28 20:57:55.694: RIP: build update entries
*Jun 28 20:57:55.698: 1.1.1.0/24 via 0.0.0.0, metric 16, tag 0
*Jun 28 20:57:55.698: 10.1.12.0/24 via 0.0.0.0, metric 1, tag 0
*Jun 28 20:57:55.702: 10.1.34.0/26 via 0.0.0.0, metric 2, tag 0
*Jun 28 20:57:55.702: 10.1.45.1/32 via 0.0.0.0, metric 2, tag 0
R2#
*Jun 28 20:58:03.346: RIP: received v2 update from 10.1.23.3 on Serial1/1
*Jun 28 20:58:03.350: 1.1.1.0/24 via 0.0.0.0 in 16 hops (inaccessible)
R2#
*Jun 28 20:58:08.602: RIP: received v2 update from 10.1.12.1 on Serial1/0
*Jun 28 20:58:08.606: 10.1.12.0/24 via 0.0.0.0 in 1 hops
*Jun 28 20:58:08.606: 10.1.23.0/24 via 0.0.0.0 in 1 hops
*Jun 28 20:58:08.606: 10.1.34.0/26 via 0.0.0.0 in 1 hops
*Jun 28 20:58:08.610: 10.1.45.1/32 via 0.0.0.0 in 1 hops
這樣就在R1和R2上產生了環路。
其實原理很簡單：
我們把R1的S1/1出口passive 了，R1 就不能把lo 0被shutdown掉的信息以flash update的形式發給R2，同時我們也把R1和R2的兩接口的水平分割關了。這時不知道情況的R2就發送更新對R1說：“你到lo 0是２跳”。而現在R1本身已經沒有了與自身直連的lo 0的０跳信息，所以它別無選擇的接受R2發來的２跳。當我們取消R1的S1/1被動功能，R1再對R2說：“你到lo 0是３跳”。雖然比原來的差，且是從同一個接口收到的，但R2它也別無選擇。就這樣它們之間就相互“欺騙”，如此循環直到出現１６跳。
l 毒性逆轉實驗：
毒性逆轉的規則是：從一個接口學習的路由會發送回該接口，但是已經被毒化，跳數設
置為16跳，不可達。
試驗拓撲同上：
這個試驗是關閉了水平分割原則的。
*Jun 28 21:06:41.486: RIP: received v2 update from 10.1.12.2 on Serial1/1
*Jun 28 21:06:41.490: 1.1.1.0/24 via 0.0.0.0 in 16 hops (inaccessible)
*Jun 28 21:06:39.418: RIP: sending v2 flash update to 224.0.0.9 via Serial1/1
(10.1.12.1)
*Jun 28 21:06:39.418: RIP: build flash update entries
*Jun 28 21:06:39.422: 1.1.1.0/24 via 0.0.0.0, metric 16, tag 0
R2#
*Jun 28 21:07:24.334: RIP: sending v2 update to 224.0.0.9 via Serial1/0
(10.1.12.2)
*Jun 28 21:07:24.334: RIP: build update entries
*Jun 28 21:07:24.338: 1.1.1.0/24 via 0.0.0.0, metric 16, tag 0
*Jun 28 21:07:24.338: 10.1.12.0/24 via 0.0.0.0, metric 1, tag 0
*Jun 28 21:07:24.342: 10.1.23.0/24 via 0.0.0.0, metric 1, tag 0
*Jun 28 21:07:24.342: 10.1.34.0/26 via 10.1.12.1, metric 2, tag 0
*Jun 28 21:07:24.346: 10.1.45.1/32 via 10.1.12.1, metric 2, tag 0
R2#
*Jun 28 21:07:26.134: RIP: received v2 update from 10.1.12.1 on Serial1/0
*Jun 28 21:07:26.138: 1.1.1.0/24 via 0.0.0.0 in 16 hops (inaccessible)
從上面可以看出：從信息也已經看到從同一個接口收到，也在同一個接口發出，但也是
已經毒化（跳數是最大跳數）
l 觸發更新的理解：
1.一旦有變化立刻發送更新（防環） 2.ip rip triggered 用於在低速鏈路上（串口），
一般情況下不發送更新，有變化的時候才會發送，類似ospf的按需電路。相當於按需電
信的周期性更新。
觸發更新和增量更新是互斥的。
觸發更新的規則是：一旦檢測到路由崩潰，立即廣播路由刷新報文，而不等到下一刷新
周期
在接口啟動trigger的話，默認在RIP中會修改hold-down時間。
timers basic 30 180 0 240
先在R1的S1/1啟動觸發更新（ip rip triggered）
R1(config)#int s1/1
R1(config-if)#ip rip triggered
查看debug信息
R1(config-if)#
*Jun 28 21:30:19.830: RIP: sending triggered request on Serial1/1 to 224.0.0.9
*Jun 28 21:30:19.834: RIP: Start poll timer from 10.1.12.1 on Serial1/1
R1(config-if)#
*Jun 28 21:30:24.834: RIP-TIMER: polling timer on Serial1/1(10.1.12.1) expired
第一次請求超時
*Jun 28 21:30:24.834: RIP: sending triggered request on Serial1/1 to 224.0.0.9
*Jun 28 21:30:24.838: RIP: Start poll timer from source 10.1.12.1 on Serial1/1
R1(config-if)#
*Jun 28 21:30:26.302: RIP-TIMER: age timer expired
R1(config-if)#
*Jun 28 21:30:29.838: RIP-TIMER: polling timer on Serial1/1(10.1.12.1) expired
第二次請求超時
*Jun 28 21:30:29.838: RIP: sending triggered request on Serial1/1 to 224.0.0.9
*Jun 28 21:30:29.842: RIP: Start poll timer from source 10.1.12.1 on Serial1/1
R1(config-if)#
*Jun 28 21:30:34.842: RIP-TIMER: polling timer on Serial1/1(10.1.12.1) expired
第三次請求超時
*Jun 28 21:30:34.842: RIP: sending triggered request on Serial1/1 to 224.0.0.9
*Jun 28 21:30:34.846: RIP: Start poll timer from source 10.1.12.1 on Serial1/1
R1(config-if)#
*Jun 28 21:30:36.302: RIP-TIMER: age timer expired
*Jun 28 21:30:36.546: RIP: received v2 update from 10.1.12.2 on Serial1/1
*Jun 28 21:30:36.550: 10.1.12.0/24 via 0.0.0.0 in 1 hops
*Jun 28 21:30:36.550: 10.1.23.0/24 via 0.0.0.0 in 1 hops
R1(config-if)#
*Jun 28 21:30:39.846: RIP-TIMER: polling timer on Serial1/1(10.1.12.1) expired
第四次請求超時
*Jun 28 21:30:39.846: RIP: sending triggered request on Serial1/1 to 224.0.0.9
*Jun 28 21:30:39.850: RIP: Start poll timer from source 10.1.12.1 on Serial1/1
R1(config-if)#
*Jun 28 21:30:44.850: RIP-TIMER: polling timer on Serial1/1(10.1.12.1) expired
第五次請求超時
*Jun 28 21:30:44.850: RIP: sending triggered request on Serial1/1 to 224.0.0.9
*Jun 28 21:30:44.854: RIP: Start poll timer from source 10.1.12.1 on Serial1/1
R1(config-if)#
*Jun 28 21:30:46.278: RIP-TIMER: sending timer on Serial1/1 expired
*Jun 28 21:30:46.302: RIP-TIMER: age timer expired
R1(config-if)#
*Jun 28 21:30:49.854: RIP-TIMER: polling timer on Serial1/1(10.1.12.1) expired
*Jun 28 21:30:49.854: RIP: Poll 6 times on Serial1/1 thru 10.1.12.1 without any
ack第六次請求超時，並且沒有收到對方的確認消息。
R1(config-if)#
*Jun 28 21:30:56.302: RIP-TIMER: age timer expired
R1(config-if)#
*Jun 28 21:31:02.290: RIP: received v2 update from 10.1.12.2 on Serial1/1
*Jun 28 21:31:02.294: 10.1.12.0/24 via 0.0.0.0 in 1 hops
*Jun 28 21:31:02.294: 10.1.23.0/24 via 0.0.0.0 in 1 hops
R1(config-if)#
*Jun 28 21:31:06.302: RIP-TIMER: age timer expired
R1(config-if)#
*Jun 28 21:31:14.646: RIP-TIMER: sending timer on Serial1/1 expired
*Jun 28 21:31:14.646: RIP: sending v2 update to 224.0.0.9 via Serial1/1
(10.1.12.1)
*Jun 28 21:31:14.646: RIP: build update entries
*Jun 28 21:31:14.646: 10.1.12.0/24 via 0.0.0.0, metric 1, tag 0
*Jun 28 21:31:14.646: 10.1.23.0/24 via 10.1.12.2, metric 2, tag 0請求無效
后，發送一次全網的更新消息。
從R1的debug調試信息中，顯示的就是R1啟動了觸發更新試圖與鏈路的另一端的R2建立觸發更新關系。R1以5s為每個周期發送輪詢（Poll）並等待確認，但發送了6個觸發請求后還沒有收到確認消息，那么整個輪詢過程就認為超時，觸發更新建立不成功，路由器R1等待下一個普通的更新時間，並廣播一個普通RIP的更新。而在整個過程R2始終在廣播着他自己的RIP更新。
此時打開R1的環回口：
*Jun 28 21:42:53.110: RIP: sending request on Loopback0 to 224.0.0.9
*Jun 28 21:42:53.114: RIP: sending request on Loopback0 to 224.0.0.9
*Jun 28 21:42:53.126: RIP: ignored v2 packet from 1.1.1.1 (sourced from one of
our addresses)
*Jun 28 21:42:53.130: RIP: ignored v2 packet from 1.1.1.1 (sourced from one of
our addresses)
R1#
*Jun 28 21:42:53.822: %SYS-5-CONFIG_I: Configured from console by console
R1#
*Jun 28 21:42:55.090: %LINK-3-UPDOWN: Interface Loopback0, changed state to up
R1#
*Jun 28 21:42:55.110: RIP: sending v2 flash update to 224.0.0.9 via Loopback0
(1.1.1.1)
*Jun 28 21:42:55.110: RIP: build flash update entries - suppressing null update
*Jun 28 21:42:56.090: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0,
changed state to up
R1#
*Jun 28 21:42:56.302: RIP-TIMER: age timer expired
R1#
*Jun 28 21:42:57.534: RIP-TIMER: neighbor sending timer of 10.1.12.2 expired
*Jun 28 21:42:57.534: RIP:retransmit seq# 7
*Jun 28 21:42:57.534: RIP: build update entries
*Jun 28 21:42:57.538: route 83: 10.1.12.0/24 metric 1, tag 0
*Jun 28 21:42:57.538: route 86: 10.1.23.0/24 metric 2, tag 0
*Jun 28 21:42:57.542: RIP: Update contains 2 routes, start 83, end 86
*Jun 28 21:42:57.542: RIP: Starting triggered retrans timer waiting on neighbor
10.1.12.2's ack.
*Jun 28 21:42:59.326: RIP-TIMER: sending timer on FastEthernet0/0 expired
*Jun 28 21:43:06.254: RIP-TIMER: sending timer on Serial1/1 expired
*Jun 28 21:43:06.302: RIP-TIMER: age timer expired
可以看到R1立即發送觸發更新給R2
R2#debug ip rip
RIP protocol debugging is on
R2#debug ip rip trigger
RIP trigger debugging is on
R2(config)#int s1/0
R2(config-if)#ip rip triggered
*Jun 28 21:39:52.878: RIP: received v2 triggered request from 10.1.12.1 on
Serial1/0
*Jun 28 21:39:52.878: RIP: Trigger rip running on network 10.0.0.0 thru Serial1/0
*Jun 28 21:39:52.882: RIP: 10.1.12.1 change state from DOWN to INIT
*Jun 28 21:39:52.882: RIP: 10.1.12.1 change state from INIT to LOADING
*Jun 28 21:39:52.886: RIP: send v2 triggered flush update to 10.1.12.1 on
Serial1/0
*Jun 28 21:39:52.886: RIP: assigned sequence number 0 on Serial1/0
*Jun 28 21:39:52.890: RIP: Update contains 2 routes, start 25, end 27
*Jun 28 21:39:52.890: RIP: received v2 triggered request from 10.1.12.1 on
Serial1/0
*Jun 28 21:39:52.894: RIP: 10.1.12.1 change state from LOADING to INIT
*Jun 28 21:39:52.894: RIP: 10.1.12.1 change state from INIT to LOADING
*Jun 28 21:39:52.898: RIP: send v2 triggered flush update to 10.1.12.1 on
Serial1/0
*Jun 28 21:39:52.898: RIP: assigned sequence number 1 on Serial1/0
*Jun 28 21:39:52.902: RIP: Update contains 2 routes, start 25, end 27
*Jun 28 21:39:52.902: RIP: received v2 triggered update from 10.1.12.1 on
Serial1/0
*Jun 28 21:39:52.922: RIP: received v2 triggered request from 10.1.12.1 on
Serial1/0
*Jun 28 21:39:52.926: RIP: 10.1.12.1 change state from LOADING to INIT
*Jun 28 21:39:52.926: RIP: 10.1.12.1 change state from INIT to LOADING
*Jun 28 21:39:52.926: RIP: send v2 triggered flush update to 10.1.12.1 on
Serial1/0
*Jun 28 21:39:52.930: RIP: assigned sequence number 2 on Serial1/0
*Jun 28 21:39:52.930: RIP: Update contains 2 routes, start 25, end 27
*Jun 28 21:39:52.998: RIP: received v2 triggered ack from 10.1.12.1 on Serial1/0
l hold-down實驗:
1：R1#debug ip routing
R1#debug ip rip
2：在R1上，做個訪問列表，不接收來自R2的rip數據包
R1(config)#access-list 110 deny udp any any eq rip
R1(config)#access-list 110 permit ip any any
R1(config-if)#ip access-group 110 in
使用默認的時間，調試過程時間較長，我們可以通過修改timer來使調試的結果更加明
顯。
R1(config)#int s1/1
R1(config-if)#no ip access-group 110 in
R1(config-router)#timer basic ?
<0-4294967295> Interval between updates
R1(config-router)#timer basic 5 ?
<1-4294967295> Invalid
R1(config-router)#timer basic 5 10 ?
<0-4294967295> Holddown
R1(config-router)#timer basic 5 10 15 ?
<1-4294967295> Flush
R1(config-router)#timer basic 5 10 15 20
R2(config)#router rip
R2(config-router)#timer basic 5 10 15 20
*Jun 28 22:05:38.330: RIP: sending v2 flash update to 224.0.0.9 via Serial1/1
(10.1.12.1)
*Jun 28 22:05:38.330: RIP: build flash update entries
*Jun 28 22:05:38.330: 2.2.2.0/24 via 0.0.0.0, metric 16, tag 0
*Jun 28 22:05:38.334: 10.1.23.0/24 via 0.0.0.0, metric 16, tag 0
*Jun 28 22:05:38.338: RIP: ignored v2 packet from 1.1.1.1 (sourced from one of
our addresses)
*Jun 28 22:05:39.378: RIP: sending v2 update to 224.0.0.9 via Loopback0 (1.1.1.1)
*Jun 28 22:05:39.378: RIP: build update entries
*Jun 28 22:05:39.378: 2.2.2.0/24 via 0.0.0.0, metric 16, tag 0
*Jun 28 22:05:39.378: 10.1.12.0/24 via 0.0.0.0, metric 1, tag 0
*Jun 28 22:05:39.382: 10.1.23.0/24 via 0.0.0.0, metric 16, tag 0
*Jun 28 22:05:39.3
R1(config-if)#82: RIP: ignored v2 packet from 1.1.1.1 (sourced from one of our
addresses)
*Jun 28 22:05:39.894: RIP: sending v2 update to 224.0.0.9 via Serial1/1
(10.1.12.1)
*Jun 28 22:05:39.894: RIP: build update entries
*Jun 28 22:05:39.898: 1.1.1.0/24 via 0.0.0.0, metric 1, tag 0
*Jun 28 22:05:39.898: 2.2.2.0/24 via 0.0.0.0, metric 16, tag 0
*Jun 28 22:05:39.898: 10.1.23.0/24 via 0.0.0.0, metric 16, tag 0
R1(config-if)#
*Jun 28 22:05:43.830: RIP: sending v2 update to 224.0.0.9 via Loopback0 (1.1.1.1)
*Jun 28 22:05:43.830: RIP: build update entries
*Jun 28 22:05:43.834: 2.2.2.0/24 via 0.0.0.0, metric 16, tag 0
*Jun 28 22:05:43.834: 10.1.12.0/24 via 0.0.0.0, metric 1, tag 0
*Jun 28 22:05:43.838: 10.1.23.0/24 via 0.0.0.0, metric 16, tag 0
*Jun 28 22:05:43.842: RIP: ignored v2 packet from 1.1.1.1 (sourced from one of
our addresses)
R1(config-if)#
*Jun 28 22:05:44.878: RIP: sending v2 update to 224.0.0.9 via Serial1/1
(10.1.12.1)
*Jun 28 22:05:44.878: RIP: build update entries
*Jun 28 22:05:44.882: 1.1.1.0/24 via 0.0.0.0, metric 1, tag 0
*Jun 28 22:05:44.882: 2.2.2.0/24 via 0.0.0.0, metric 16, tag 0
*Jun 28 22:05:44.886: 10.1.23.0/24 via 0.0.0.0, metric 16, tag 0
R1(config-if)#
*Jun 28 22:05:46.326: RT: delete subnet route to 2.2.2.0/24
*Jun 28 22:05:46.326: RT: NET-RED 2.2.2.0/24
*Jun 28 22:05:46.330: RT: delete network route to 2.0.0.0
*Jun 28 22:05:46.330: RT: NET-RED 2.0.0.0/8
*Jun 28 22:05:46.334: RT: delete subnet route to 10.1.23.0/24
*Jun 28 22:05:46.334: RT: NET-RED 10.1.23.0/24
R1(config-if)#
*Jun 28 22:05:48.798: RIP: sending v2 update to 224.0.0.9 via Loopback0 (1.1.1.1)
*Jun 28 22:05:48.798: RIP: build update entries
*Jun 28 22:05:48.802: 10.1.12.0/24 via 0.0.0.0, metric 1, tag 0
*Jun 28 22:05:48.806: RIP: ignored v2 packet from 1.1.1.1 (sourced from one of
our addresses)
*Jun 28 22:05:49.654: RIP: sending v2 update to 224.0.0.9 via Serial1/1
(10.1.12.1)
*Jun 28 22:05:49.654: RIP: build update entries
*Jun 28 22:05:49.658: 1.1.1.0/24 via 0.0.0.0, metric 1, tag 0
總結：在距離矢量路由協議里面，路由器會將它學習的整張路由表信息更新發出去，Ｒ
ip使用４種計時器來管理它的性能：
1：周期更新計時器周期更新計時器用於設置定期路由更新的時間間隔（一般為３０
s），在這個間隔里路由器發送一個自己路由表的完整拷貝到所有相鄰的路由器。
2：無效計時器用於決定一個時間長度，即路由器在認定一個路由成為無效路由之前
所需要等待的時間（１８０s，實際情況往往略大於１８０s）．如果路由器在更新計時
器期間沒有得到關於某個指定路由的任何更新消息，它將認為這個路由失效，這時就會
進入到無效計時器階段．當這一情況發生時，這個路由器將會給它所有的鄰居發送一個
更新消息以通知它們這個路由已經無效。
3：保持計時器用於設置路由信息被抑制的時間數量．當上述無效計時器計時完畢后，
就會進入到保持計數器階段．也可理解為，當指示某個路由為不可達的更新數據包被接
受到時，路由器將會進入保持失效狀態．這個狀態將會一直持續到一個帶有更好度量的
更新數據包被接受到或者這個保持計時器到期．默認時，它的取值是１８０s．在進入
到這個階段的前６０s，會顯示一個如下的路由信息possibly down，這時路由器並沒有
直接刪除這條路由信息，但記住，若此時該路由恢復正常通訊，路由表信息也不會更新，
在接下來的１２０s會起到一個保持網絡穩定的作用。
4：刷新計時器用於設置某個路由成為無效路由並將它從路由表中刪除的時間間隔（２
４０s）．這個計時器是剛開始就啟動的，一直到保持計時器進行到６０s時，它將路由
表刷新．在將它（無效路由）從表中刪除前，路由器會通告它的鄰居這個路由即將消亡。
5:我們也可以用time basic 來改變計時器的時間間隔。
timers basic update invalid holddown flush