怎么排除錯誤的CMP重定向

時間：2016-03-23 16:09:22 權威724由分享

　　世界領先的企業網絡解決方案，及數字家庭網絡應用倡導者美國網件公司，他出產的netgear路由器設備功能強大，那么你知道怎么排除錯誤的CMP重定向嗎?下面是學習啦小編整理的一些關于怎么排除錯誤的CMP重定向的相關資料，供你參考。

　　排除錯誤的CMP重定向的方法：

　　拓撲

　　配置參數

　　FVS318G NAT模式，外網接口以實際情況配置，本例擬為123.123.123.122/30，默認路由123.123.123.121， LAN IP 172.16.0.1

　　FVS318N路由模式(由于禁用了NAT，設備已無所謂哪一側是WAN，哪一側是LAN，本例中我們會仍然沿用設備前面板印刷接口名稱)，WAN IP 172.16.0.100/24， LAN IP 172.16.1.1/24，默認路由 172.16.0.1

　　SRX5308路由模式，WAN IP 172.16.1.100/24，LAN IP 172.16.2.1/24，默認路由172.16.1.1

　　PC1 IP 172.16.2.2/24 網關172.16.2.1

　　PC2 IP 172.16.0.7/24 網關 172.16.0.1

　　三臺防火墻LAN-WAN間進出站均allow any any

　　三臺防火墻各接口響應ping，允許內外網登錄

　　三臺防火墻使用RIPv1協議互通路由信息。

　　三臺防火墻均關閉DHCP，拓撲中涉及所有接口或網卡IP手工配置。

　　PC2網卡MAC為CadmusCo_XX:6a:70

　　FVS318G LAN MAC為Netgear_XX:e1:b1

　　FVS318N WAN MAC為Netgear_XX:bf:ef

　　故障描述

　　當FVS318G LAN管理地址配置為24位掩碼時PC1可以ping通PC2，可以訪問互聯網

　　當FVS318G LAN管理地址設為16位掩碼時PC1無法ping通PC2

　　排錯思路與步驟

　　查看FVS318G路由表，尋找子網掩碼的修改對路由表的影響.下圖為LAN掩碼為24位時FVS318G的路由表，其中有前往網絡172.16.2.0的條目

　　Interface NameDestinationMaskGatewayMetric

　　BroadBand123.123.123.121255.255.255.2520.0.0.00

　　BroadBand123.123.123.121255.255.255.252123.123.123.1221

　　LAN172.16.2.0255.255.255.0172.16.0.1003

　　LAN172.16.0.0255.255.255.00.0.0.00

　　LAN172.16.0.0255.255.255.0172.16.0.11

　　LAN172.16.1.0255.255.255.0172.16.0.1002

　　BroadBanddefault0.0.0.00.0.0.00

　　將FVS318G LAN掩碼改為16位并查看路由表

　　Interface NameDestinationMaskGatewayMetric

　　BroadBand123.123.123.121255.255.255.2520.0.0.00

　　BroadBand123.123.123.121255.255.255.252123.123.123.1221

　　LAN172.16.0.0255.255.0.00.0.0.00

　　LAN172.16.0.0255.255.0.0172.16.0.11

　　BroadBanddefault0.0.0.00.0.0.00

　　在FVS318G LAN掩碼為16位時，PC2 ping往172.16.2.2的數據包會根據PC2的默認路由丟給172.16.0.1(FVS318G LAN)

　　由于此時FVS318G LAN掩碼為16位， FVS318G會認為172.16.2.2與自己的LAN在同一網絡，FVS318G將嘗試根據ARP表封裝172.16.2.2的數據鏈路層地址，并將數據直接丟到FVS318G所認為直連的PC1。

　　由于FVS318G ARP表中沒有172.16.2.2條目，設備將會以廣播形式請求172.16.2.2 MAC地址，我們可以在FVS318G的LAN側抓包以驗證這一觀點，

　　如上圖所示，由于FVS318G無法知曉172.16.2.2的鏈路層地址，目的MAC地址也就無從填寫，ping包甚至從來都不會從FVS318G的LAN側發送出去.

　　在FVS318G LAN側抓包時我們會發現，除了FVS318G LAN發出的ARP請求外，PC2也在請求172.16.2.2的MAC地址

　　為了說明步驟7的成因，我們將FVS318G LAN掩碼改為24位，從PC2 ping往PC1并在PC2上抓包查看

　　對比步驟8截圖中的數據包7和數據包14

　　步驟8與9的截圖中我們可以發現，同樣是由172.16.0.7發往172.16.2.2的數據包，數據包7與數據包14的目的MAC地址是不同的.數據包7目的MAC為FVS318G的LAN;數據包14目的地址為FVS318N的WAN。

　　造成上述這一改動的原因是步驟8中的數據包10，我們來看一下數據包10的詳細內容

　　步驟11中我們可以看到，數據包10(ICMP重定向)由FVS318G發往PC2，告知PC2去往172.16.2.2(PC1)的數據包可以直接丟向172.16.0.100(這是因為路由器發現自己不是最優路徑)。

　　當傳遞的數據包不是源地址路由數據包，且路由器內核被設置為可發送ICMP重定向的情況下，如果數據包源IP與下一跳IP在同一網絡或者路由器即將轉發數據包的接口與收到這個數據包的接口相同時，路由器會在轉發這個數據包后向數據來源發送一個ICMP重定向，以通告更優路徑。

　　本例中，如果PC2對應網卡的secure_redirect與accept_redirect設置為TURE，且ICMP重定向的發送源為PC2的默認網關(172.16.0.1)時，PC2會接受這條ICMP重定向，并將發往PC1數據包的下一跳改為FVS318N WAN口(如數據包14所示).在步驟8的截圖中可見，PC2在接收到數據包10( ICMP重定向)后在數據包11中請求了新的下一跳(FVS318N WAN)數據鏈路層地址，并在緊接著的ping請求(數據包14)中得以體現。

　　接下來我們可以在PC2上驗證這一更新，首先ping PC1。

　　參考步驟8與步驟15的截圖可知，首2數據包被發往了默認網關(FVS318G LAN)，在PC2收到了來自FVS318G(172.16.0.100)的ICMP重定向后，余下的數據包將直接丟給FVS318N WAN口(172.16.0.100)。

　　此時您可能期望在PC2的路由表中看到更新的H路由條目以驗證ICMP重定向對PC2的改變，但結果可能令人失望。

　　PC2的路由表并未得以更新，原因是在轉發數據包時，Linux kernel將優先匹配路由緩存，而后才是路由表.ICMP重定向更改的恰為此緩存表。

　　至此我們也回答了步驟7中提出的問題，PC2正是由于收到了FVS318G發出的ICMP重定向，所以試圖將數據包直接發往PC1(172.16.2.2)，故而發送ARP請求PC1的鏈路層地址。

　　看過文章“怎么排除錯誤的CMP重定向"的人還看了：

　　1.路由器的配置基礎知識

　　6.靜態路由配置解析