ICMP重定向字段的路由重定向實驗

ICMP重定向字段的路由重定向實驗

ICMP的重定向字段,被路由器用於通知主機去往目標的最佳網關,是數據鏈路上的另一臺路由器。

 

實驗目的:

1.         驗證重定向。

2.         重定向對主機的數據轉發的影響。

3.         關閉重定向後,數據轉發過程。

 

實驗拓撲:

實驗設計:

1.         R2R3R4R5運行RIPv2協議,R1關閉路由功能,將默認網關指向R2

2.         R4R5上各有環回接口,IP分別爲4.4.4.45.5.5.5,所有IP地址使用/24位地址。

3.         在驗證過重定向後,關閉R2 F0/0的路由重定向功能,通過抓包,查看數據轉發路徑。

 

實驗過程:

各路由器的配置在此就不寫了,直接來驗證實驗結果。

 

首先先對拓撲進行分析,從拓撲上看,R1發往R4的數據,其最短路徑應爲R1R3——R4R1發往R5的數據,其最短路徑應爲R1R2R5。我們通過抓包,來分別檢驗到R4R5的數據轉發路徑。當然在開始前要做些準備工作:

 

1.         R1上使用debug ip icmp命令來開啓debug信息。

2.         關閉R2 F0/0接口的路由重定向功能,應爲該功能是默認開啓的,命令如下:

 

1.關閉R2路由重定向功能時的數據傳輸路徑

1.1 R1ping 5.5.5.5

   

ping通後,看看抓包的結果,查看R1F0/0口即可

 

1  R1 ping請求抓包

 

2  R1 ping應答抓包

 

 

從請求及應答包的二層頭部可以看出,R1的數據發向了R2,因爲R2運行有RIP協議,故數據包將由R2轉給R5

1.2 R1ping 4.4.4.4

 

3  R1 ping 4.4.4.4 請求抓包

 

4  R1 ping 4.4.4.4 應答抓包

 

 

爲了更好的說明問題,再在R3 f0/0上進行抓包

 

5  R3上抓取的ping請求包

 

6  R3上抓取的ping應答包

 

 

 

由圖3可看出,R1R4ping請求首先發向了ca00.0518.0000R2),由圖4可看出,直接向R1轉發此次ping應答的是ca02.0518.0000R3)。

由圖5可看出,ca01.0518.0000R2)發送過來一個ping請求,由圖6可看出,對於這個ping請求,做出的應答R3直接發向了ca00.0518.0000R1)。

 

意即,當關閉重定向時,關於此次ping的全過程的路徑是R1R2R3R4(數據到達R4,開始回包)—R3R1。一去一回是所經過的路徑不一樣,也就是產生了不對稱的流量。同時,不進行重定向,在有時間間隔的ping過程中,存在丟包顯現,意即數據鏈路的可靠性較低。

 

2.開啓R2的路由重定向功能

因爲路由重定向功能主要是針對於去往R4的數據流量,故可不再進行ping R5的實驗。

 

R1 ping 4.4.4.4,結果如圖7。由圖7中可看出,當R1 ping 4.4.4.4後,產生了一條重定向提示:接收到來自123.1.1.2的重定向信息—去往4.4.4.4使用網關123.1.1.3

 

7  R1 ping 4.4.4.4debug信息

 

接着,在查看一下R1此時的路由表,如圖8

 

8  R1路由表

 

 

此時,可發像,R1的缺省網關仍爲123.1.1.2,只是路由表中多了一條明細信息,將去往4.4.4.4的網關指向了123.1.1.3

下面將34.1.1.334.1.1.4ping通,通時再ping一下34.1.1.0/24網段的其他地址,看看R1路由表信息,如圖9

 

9  R1路由表

 

   

由圖9可看出,雖然,34.1.1.534.1.1.6是不存在的主機地址,但是仍被重定向到了R3。這是因爲R2使用的是RIP協議,擁有到達34.1.1.0/244.4.4.0/24網段的路由,因此在R2查看過自己路由表後,會將所有去往34.1.1.0/244.4.4.0/24網段的數據全部重定向到R3。在路由表中Last Use是距上一次使用時的時間,Total uses應該是使用的頻次。

 

在進行下一步的路徑驗證之前,我們先看一下抓包工具抓出來的重定向ICMP包,如圖10

 

從圖10中,從而三層頭部信息中可知這是有R2發給R1的信息,在ICMP消息中,可看出類型爲5,代碼爲1,校驗和爲0x2b19,重定向到123.1.1.1,再其後便表明爲哪個地址進行的重定向。

 

10  重定向ICMP抓包

 

現在開始進行路勁驗證,同樣還是通過分析抓到的ping包來進行,如圖1114

 

11  ping R4的請求包

 

 

12  ping R4的應答包

 

 

13  ping R5的請求包

 

 

14  ping R5的應答包

 

 

 

由圖1112可看出,去往R4的流量均直接使用R3進行傳輸,而不再使用R2,即網關被重定向到R3;由圖1314可看出,去往R5的流量仍有R2進行處理,即網關仍未R2

 

3.一個解決路由從定向問題的方法

卷一中提供了一個避免路由重定向的方法,就是主機將網關指向自己的接口,下面開始驗證一下,結果如圖1516所示。

 

15  R1 ping R5(有缺省網關)

 

16  R2 debug信息

 

 

 

由圖15debug信息可知,數據包已經形成併發送到f0/0口(網關),而從圖16 R2debug信息中,卻沒有發現有數據經過,且也爲接受到ARP的請求。由此可是,在用路由器模擬主機的實驗環境下,這個解決方案是不成立的。但是我可以肯定的說,當主機將網關指向自己的以太網口的時,再ping不同網段的的主機是會發出ARP請求的,也就是說真實主機將網關指向自己的時候,在這種情況向的確可以避免路由重定向。關於主機將網關指向自己時的ARP實驗結果,見下次實驗。

 

當然,在這中路由器模擬主機的環境下,採用卷一中的提示,避免路由重定向也是可實現的。通過上一次的代理ARP實驗可知,當用路由器模擬的主機在不指網關的時候,要與不同網段數據通信的時候也是會發送ARP請求的。因此,要先將R1的默認網關清掉,然後再ping R5,結果如圖17所示。

 

由圖17中可發現,當R1 ping 5.5.5.5的時候,首先發送了關於5.5.5.5MAC地址的ARP查詢,第一個包由於還未接到應答,不知道二層頭部信息,因此封裝失敗。黃色的框中顯示,R1收到的關於5.5.5.5ARP應答,指明5.5.5.5MAC地址是ca01.0518.0000R2MAC地址,因爲默認代理ARP功能是打開的)。同樣,ping 4.4.4.4的時候,R1也會發送ARP查詢,MAC地址將由R3來代理,如圖17中的ARP表,意即去往R4的數據將交由R3來轉發。

這種做法的確避免了路由重定向,不過卻加重了網絡的負擔,因爲ARP請求使用的是廣播,而在指明網關後,使用的均爲單播信息。

另外需說明一點,在此實驗中,R1發出了ARP請求,而R2R3均有到達兩個網段的路由,只從這點考慮的話,R1的每個ARP請求應該會接到兩個ARP應答。但是實際上R1每個ARP請求只收到了一個準確的最近網關的ARP代理應答,而通過抓包也發現,R2R3均未爲要使用接受ARP請求的端口發送數據的ARP請求做應答。即R2未給向4.4.4.4的請求做應答,因爲去往4.4.4.4的數據讓要從f0/0口(接受4.4.4.4 ARP請求的端口)發出;同樣R3未給向5.5.5.5的請求做應答。這也就是說路由器的代理ARP功能是爲其它端口進行代理,也就是說當路由器判定數據讓要從接受ARP請求的端口轉發,將不會應答此請求。

 

由以上過程,我又想到一個實驗,即如果R2R3爲同一個網絡開啓了負載均衡,那麼R1會接受誰的ARP代理,此實驗留待下次解決。

 

17  R1 ping R5 debug信息(無網關)

 

 

總結

1.         當路由器從一個接口接到一個數據,經查詢過路由表,判定仍要從接收該數據接口發送該數據時,將會向原目標發送重定向的ICMP消息。

2.         不使用路由重定向功能,會造成不對稱流量,並且鏈路可靠性降低。

3.         主機將網關指向自己可避免路由重定向的問題,但會造成ARP流量的增加。

4.         路由器模擬主機,在配置缺省網關(即使網關指向自己)之後,將不會發出不同網段的ARP請求,這與未配置網關的主機相同;而主機在將網關指向自己之後,會發出不同網段的ARP請求,這與未配置缺省網關的路由器模擬的主機相同。

5.         路由器的代理ARP功能是爲其它端口進行代理的,也就是說當路由器判定數據仍要從接受ARP請求的端口轉發時,將不會應答此請求。

 

留待解決問題

1.         主機將網關指向自己後,進行不同網段ARP查詢的實驗。

2.         當一臺模擬主機的路由器連到兩臺對同一網絡進行了負載均衡配置的網絡,代理ARP情況如何?

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章