ICMP重定向字段的路由重定向實驗
ICMP的重定向字段，被路由器用于通知主機去往目標的最佳網關，是數據鏈路上的另一臺路由器。
實驗目的：
1.驗證重定向。
2.重定向對主機的數據轉發的影響。
3.關閉重定向后，數據轉發過程。
實驗拓撲：
實驗設計：
1.R2、R3、R4、R5運行RIPv2協議，R1關閉路由功能，將默認網關指向R2
2.R4、R5上各有環回接口，IP分別為4.4.4.4、5.5.5.5，所有IP地址使用/24位地址。
3.在驗證過重定向后，關閉R2 F0/0的路由重定向功能，通過抓包，查看數據轉發路徑。
實驗過程：
各路由器的配置在此就不寫了，直接來驗證實驗結果。
首先先對拓撲進行分析，從拓撲上看，R1發往R4的數據，其最短路徑應為R1—R3——R4；R1發往R5的數據，其最短路徑應為R1—R2—R5。我們通過抓包，來分別檢驗到R4，R5的數據轉發路徑。當然在開始前要做些準備工作：
1.在R1上使用debug ip icmp命令來開啟debug信息。
2.關閉R2 F0/0接口的路由重定向功能，應為該功能是默認開啟的，命令如下：
1.關閉R2路由重定向功能時的數據傳輸路徑
1.1 在R1上ping 5.5.5.5
ping通后，看看抓包的結果，查看R1的F0/0口即可
圖1 R1 ping請求抓包
圖2 R1 ping應答抓包
從請求及應答包的二層頭部可以看出，R1的數據發向了R2，因為R2運行有RIP協議，故數據包將由R2轉給R5。#p#
1.2 在R1上ping 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可看出，R1向R4的ping請求首先發向了ca00.0518.0000（R2），由圖4可看出，直接向R1轉發此次ping應答的是ca02.0518.0000（R3）。
由圖5可看出，ca01.0518.0000（R2）發送過來一個ping請求，由圖6可看出，對于這個ping請求，做出的應答R3直接發向了ca00.0518.0000（R1）。
意即，當關閉重定向時，關于此次ping的全過程的路徑是R1—R2—R3—R4（數據到達R4，開始回包）—R3—R1。一去一回是所經過的路徑不一樣，也就是產生了不對稱的流量。同時，不進行重定向，在有時間間隔的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.4的debug信息
接著，在查看一下R1此時的路由表，如圖8。#p#
圖8 R1路由表
此時，可發像，R1的缺省網關仍為123.1.1.2，只是路由表中多了一條明細信息，將去往4.4.4.4的網關指向了123.1.1.3。
下面將34.1.1.3、34.1.1.4也ping通，通時再ping一下34.1.1.0/24網段的其他地址，看看R1路由表信息，如圖9。
圖9 R1路由表
由圖9可看出，雖然，34.1.1.5及34.1.1.6是不存在的主機地址，但是仍被重定向到了R3。這是因為R2使用的是RIP協議，擁有到達34.1.1.0/24及4.4.4.0/24網段的路由，因此在R2查看過自己路由表后，會將所有去往34.1.1.0/24及4.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包來進行，如圖11～14。
圖11 ping R4的請求包
圖 12 ping R4的應答包
圖 13 ping R5的請求包#p#
圖 14 ping R5的應答包
由圖11、12可看出，去往R4的流量均直接使用R3進行傳輸，而不再使用R2，即網關被重定向到R3；由圖13、14可看出，去往R5的流量仍有R2進行處理，即網關仍未R2。
3.一個解決路由從定向問題的方法
卷一中提供了一個避免路由重定向的方法，就是主機將網關指向自己的接口，下面開始驗證一下，結果如圖15、16所示。
圖15 R1 ping R5（有缺省網關）
圖 16 R2 debug信息
由圖15中debug信息可知，數據包已經形成并發送到f0/0口（網關），而從圖16 R2的debug信息中，卻沒有發現有數據經過，且也為接受到ARP的請求。由此可是，在用路由器模擬主機的實驗環境下，這個解決方案是不成立的。但是我可以肯定的說，當主機將網關指向自己的以太網口的時，再ping不同網段的的主機是會發出ARP請求的，也就是說真實主機將網關指向自己的時候，在這種情況向的確可以避免路由重定向。關于主機將網關指向自己時的ARP實驗結果，見下次實驗。
當然，在這中路由器模擬主機的環境下，采用卷一中的提示，避免路由重定向也是可實現的。通過上一次的代理ARP實驗可知，當用路由器模擬的主機在不指網關的時候，要與不同網段數據通信的時候也是會發送ARP請求的。因此，要先將R1的默認網關清掉，然后再ping R5，結果如圖17所示。
由圖17中可發現，當R1 ping 5.5.5.5的時候，首先發送了關于5.5.5.5的MAC地址的ARP查詢，第一個包由于還未接到應答，不知道二層頭部信息，因此封裝失敗。黃色的框中顯示，R1收到的關于5.5.5.5的ARP應答，指明5.5.5.5的MAC地址是ca01.0518.0000（R2的MAC地址，因為默認代理ARP功能是打開的）。同樣，ping 4.4.4.4的時候，R1也會發送ARP查詢，MAC地址將由R3來代理，如圖17中的ARP表，意即去往R4的數據將交由R3來轉發。
這種做法的確避免了路由重定向，不過卻加重了網絡的負擔，因為ARP請求使用的是廣播，而在指明網關后，使用的均為單播信息。
另外需說明一點，在此實驗中，R1發出了ARP請求，而R2、R3均有到達兩個網段的路由，只從這點考慮的話，R1的每個ARP請求應該會接到兩個ARP應答。但是實際上R1每個ARP請求只收到了一個準確的最近網關的ARP代理應答，而通過抓包也發現，R2、R3均未為要使用接受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請求的端口轉發，將不會應答此請求。
由以上過程，我又想到一個實驗，即如果R2、R3為同一個網絡開啟了負載均衡，那么R1會接受誰的ARP代理，此實驗留待下次解決。
圖 17 R1 ping R5 debug信息（無網關）
總結
1.當路由器從一個接口接到一個數據，經查詢過路由表，判定仍要從接收該數據接口發送該數據時，將會向原目標發送重定向的ICMP消息。
2.不使用路由重定向功能，會造成不對稱流量，并且鏈路可靠性降低。
3.主機將網關指向自己可避免路由重定向的問題，但會造成ARP流量的增加。
4.路由器模擬主機，在配置缺省網關（即使網關指向自己）之后，將不會發出不同網段的ARP請求，這與未配置網關的主機相同；而主機在將網關指向自己之后，會發出不同網段的ARP請求，這與未配置缺省網關的路由器模擬的主機相同。
5.路由器的代理ARP功能是為其它端口進行代理的，也就是說當路由器判定數據仍要從接受ARP請求的端口轉發時，將不會應答此請求。
