RIP定時器研究2

1、各位 我來說說 RIP 幾大定時器之我見更新30 失效定時180 抑制180 刷新240 可以用上圖來說明我理解的過程 我們來說常規(guī)的：周期更新 好理解 30S 定期發(fā)送全部的路由更新 是站在發(fā)送方這邊來看的 當(dāng)然有水平分割的存在和network沒有的緣故不一定是定期發(fā)送全部的路由再提下這個30S往往并不絕對 其實是25S-30S 失效定時器 也好理解的吧 倒過來想 我的鄰居周期性30S給我發(fā)路由更新 意味著我應(yīng)當(dāng)每隔30S就會收一次 如果 我180S都沒有收到更新就失效了 這個就是失效定時器 可以看出它的啟點 就是我收到定

2、期路由信息 就開始計時。 其實 它是站在 收這邊的角度來看的 而且是針對路由條目的失效后 怎么樣呢 他會標(biāo)記這個路由 可能down了(但查看路由表時還存在這條路由只不過已被標(biāo)記為可能Down) 與此同時 抑制定時器從 結(jié)束的哪個時刻后立即開始計時 講到這里 我不能說這是抑制定時器啟動的唯一理由因為我還沒有對此做唯一性論證當(dāng)然也存在另種激發(fā)抑制定時器開始的可能與條件吧 繼續(xù)吧 資料和show 來看都說這個是180S 先把這個提這里了 我們又來看刷新計時器 它與失效定時器一樣 站在收這邊的角度 而且也同失效定時器一起計時的 也針對具體路由條目 240S刪除沒有收到的路由更新的這條路由表項 這個是法

3、則死的 有種說法叫 我一旦收到 我本來從你處知道的路由你卻又給我傳來從你處不能去了的路由信息（不能理解為失效而是在周期內(nèi)也許應(yīng)當(dāng)說在失效定時期內(nèi)明明白收到你發(fā)我的跳的路由信息的這種情況） 會立即啟動抑制計時器 另外一種說法是 無效計時器到時后 （是失去丟失沒有收到更新的情況）才 立即的啟動了 抑制定時器 哪么以上兩種說法有問題嗎是其中之一是正確的 還是兩種都對或是都錯呢 補(bǔ)充一點 這兩種有本質(zhì)不同啊 前面一種是 你明確給我講你去不了目的 第二種呢 是我沒有收到你發(fā)的周期更新，我自已判斷認(rèn)為不可達(dá) 隨后我還要把我的認(rèn)為不可達(dá) 傳遞給我所有的鄰居=抑制定時器 反正是要等 等什么 等我失去的哪個路由

4、（超過無效計時器規(guī)定時間被標(biāo)為可能down） 能恢復(fù)(在沒有超出抑制定時器規(guī)定的時間收到失去的路由)I 。如果能恢復(fù) 哪么路由器從新標(biāo)記被可能down的路由為可用可達(dá) 并將除周期更新的其它個計時器重置； 如收到更好的路由(這里僅指路由相同但度理值更優(yōu))我加入路由表也將除周期更新的其它個計時器重置這期間 有如果有更差的路由進(jìn)來的話 我在抑制定時器規(guī)定的時間內(nèi) 則 忽略這個路由更新 這是其中說法之一 這個工作機(jī)制前提是 我失去路由的前提哪么另種呢 以前這個路由是你給我的 現(xiàn)在你又明明白白傳過來一個16跳 說不能通過你到達(dá)了 我也立即的啟動抑制的定時器這是另外一種說法隨后的法則和前面一樣 哪么以上兩

5、種說法有問題嗎是其中之一是正確的 還是兩種都對呢還是有特定的情形下后者對呢 以上為從各種資料上所述的情形。說到這里大家不知發(fā)現(xiàn)問題了沒有 有這60S 他屬于刷新計時器 又屬 抑制定時器 哪么這個60S 到底是拒絕接受呢 還是要接受呢 應(yīng)當(dāng)要吧 因為不是有前面說的邏輯判斷法則的呀又如過完這抑制定時器并沒有完都還有120可是前面提到刷新計時器到期了(即失效定時器到期并標(biāo)為可能down的路由又過了，)它會無條件的刪除這個路由，而抑制定時器并沒有完都還有120，是不是同樣會被抑制呢注：flush計時器是和invalid計時器一起開始計時的 所以總共240秒一到 本路由就會被清除掉,而不是等到 hold

6、down的180秒走完 總共要等invaild+holddown=180+180=360, 實際的時間最高就是240秒左右(有一定的偏差） 所以240S刪除沒有收到的路由更新的這條路由表項 這個是法則死的 綜上是不是有這些問題和矛盾啊 不知這些問題在你的心中有怎樣的判斷?我想我們首先要解決的是什么時候啟動抑制的定時器驗證兩種啟動抑制定時器激活條件也就是說看前面說的兩種情形是都對還是都不對還是其中之一對把這個問題 搞清了 再來看抑制定時器內(nèi)收到路由（不同度量值）的后繼動作和沒有收到的后繼動作 是不是如理論說講的哪樣一致的須要設(shè)計好幾個實驗來觀察 實驗 由易到難 逐步深入 依上圖 運行 全部運行

7、rip v1 在 R1上 建lo0 100.100.100.1/24并參與rip； 收斂完畢后 打開 R2 R3 R4 的 調(diào)試信息 debug ip routing 及 debug ip rip 將 R1 的 F0/0中設(shè)為被動接口 在300S內(nèi) 觀察 R2 R3 R4的 調(diào) 試信 息 此項實驗來觀察 丟失路由（也就是說失效定時器到期都還沒有收到的這種情形）我先來分析一下 或者說 對實驗結(jié)果的一個預(yù)測 當(dāng)正常收斂完畢后 ，R1會以30S周期的將100.0.0.0的更新發(fā)給R2 且周期更新中也只會包含這一條路由對外發(fā)布并且通過R1的F0/0 這個大伙經(jīng)過的學(xué)習(xí)對這個都應(yīng)當(dāng)認(rèn)同的吧；當(dāng) R1 的

8、 F0/0設(shè)為被動接口后，R2將收不到此條路由信息了(來模擬丟失傳來的100.0.0.0) 如果到了180S 還是沒有收到 R2路由器在自己的路由表中把該路由條目設(shè)置為可能丟失(possibly down)；隨后R2將把該路由條目設(shè)置為不可達(dá)(Metric為16)通過自身參與rip的各個接口更新出去這是個毒化路由。這里有個問題當(dāng)R2在失效定時期180S內(nèi) R2的路由表依然有正常的 100.0.0.0這個路由表項 會按30S一個周期給R3發(fā)的 ，所以 R2 就算在無效計時期內(nèi)沒有收到 這個更新 但它并不影響我的正常工作。只有當(dāng)過了無效定時期時 路由器才會把該路由條目設(shè)置為可能丟失(possibl

9、y down)；且開始了抑制計時器的計時并把該路由條目設(shè)置為不可達(dá)(Metric為16)通過自身參與rip的各個接口更新出去。接下來R3收到這個16條的毒化路由 會怎么辦呢 R4又是怎么辦的呢 隨著時間的流失R2收不到100.0.0.0的路由又過了60S 到達(dá)了 240S 了 這下刷新計進(jìn)器到期了 我R2 肯定會從路由表中刪了關(guān)于100.0.0.0的路由表項 和我分析的結(jié)果會一樣嗎 我們通過實驗來看吧我們看R2的調(diào)試信息：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設(shè)成了被動接口的原因）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 已經(jīng)過

12、了180S 可R2 還沒有對此路由條目有反應(yīng) 這也說明 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 有反應(yīng)了 *Mar 1 00:21:16.867: RT: SET_LAST_RDB for 100.0.0.0/8 設(shè)置此條路由在 rip 數(shù)據(jù)庫中 為丟失 可能down狀態(tài) 這時查看路由表肯定還會有顯示這個路由不過表明了是可能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 隨后立即進(jìn)入 抑制狀態(tài) 并開始抑制計時器的計時 從無效到期到啟動抑制計時僅隔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) 并將該路由條目設(shè)置為不可達(dá)(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) 并將該路由條目設(shè)置為不可達(dá)(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 會怎么 做呢 我應(yīng)當(dāng)把R3 的調(diào)試信息 部份插入到這里來看 R3#*Mar 1 00:21:10.591: RIP: received v1 update from 23.23.23.2 on FastEthernet2/0 它從R2收到了關(guān)于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) 而且 也快速的轉(zhuǎn)發(fā)了 這個毒化路由 發(fā)給了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) 而且也又把這個 發(fā)回給了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發(fā)回來的毒化路由 證明R4回發(fā)了這個毒化路由*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 繼續(xù)收到收到R4發(fā)回來的毒化路由 證明R4回發(fā)了這個毒化路由*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 續(xù)續(xù)收到R2發(fā)來的毒化路由*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) 我又繼續(xù)發(fā)給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) 我又繼續(xù)發(fā)給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發(fā)來的毒化*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發(fā)來的毒化*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、發(fā)給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) 又發(fā)給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接口 發(fā)出毒化路由 且 可以看出毒化路由不受 周期更新 與 水平分割的影響= 看完插入的R3 信息 再來插入 R4的調(diào)試信自息吧 請看 R4#*Mar 1 00:21:26.551: RIP: received v1 update from 34.34.34.3 on FastEthern

27、et0/0 我收到了R3發(fā)來的 毒化路由*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的所有接口 發(fā)出 毒化的路由包括又發(fā)給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 通過這個口還在 發(fā) 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 又通過這個口發(fā)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收到 毒化的不可達(dá)的路由信息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# 上面收發(fā)是能和R3對應(yīng)得上的 以上R4又是怎么樣的邏輯呢 其實和R3的一模一樣 我一收到 16跳的毒化路由 我立即就從路由表中刪除了這條路由項 并且也像我的所有參與rip接口 發(fā)出毒化路由 且 可以看出毒化路由不受 周期更新 與 水平分割的影響=我們再次回到 R2上來解讀報調(diào)試信息吧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 接收到了 關(guān)于這條的毒化路由 并且是我始發(fā)的 確又傳回給我了 再次證明他不受水平分割的影響*Mar 1 00:21:20.919: RT: 100.0.0.0 came out of holddown 這條說明我收到了一條關(guān)于100.0.0.0的路由 我就從 holdown狀態(tài)中走出 或出來 =疑問：難到只要收到同樣的路由就結(jié)束了抑制狀態(tài)嗎？還是只有在我這樣的拓樸與編址設(shè)計中才會是這樣的呢 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 繼續(xù)向外發(fā) 毒化路由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 繼續(xù)向外發(fā) 毒化路由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) 繼續(xù)收到 毒化路由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 繼續(xù)向外發(fā) 毒化路由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 繼續(xù)向外發(fā) 毒化路由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) 繼續(xù)收到 毒化路由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復(fù)制到這里來看 好做時間對比 從失效定時器到期并且開始抑制定時器計時 后60S(本次實驗剛好是60S) 到了 240S也就是刷新計時器到點 R2 無條件的 從路由表刪除了這條路由表項 這里時間還比較準(zhǔn) *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 從這里看已經(jīng)沒有了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好至此我們結(jié)束了 這個實驗 好像一切都如書中和資料上講的 但有個非常值得注意的調(diào)試信自息 我復(fù)制過來 請看下面： 這個很關(guān)鍵啊 這次 提出來讓大家 有個印像 知道有這么回事 就行 好這個實驗 完成 。 我們梳理幾個關(guān)鍵點：當(dāng)不能定期30從先前的“源”收到100.0.0.0的路由通