IPv6路由查找順序

-1

bash-3.00# /usr/sbin/ip -6 route show 
default via fdc6:3001:8e20:9ce9::1 dev int0 metric 1024 expires 2133437sec mtu 1500 advmss 1440 metric10 4294967295 
unreachable default dev lo proto none metric -1 error -101 metric10 255 
unreachable default dev lo proto none metric -1 error -101 metric10 255 
unreachable default dev lo proto none metric -1 error -101 metric10 255 
fdc6:3001:8e20:b06::/64 dev ext0 metric 256 expires 2132985sec mtu 1500 advmss 1440 metric10 4294967295 
fdc6:3001:8e20:9ce9::/64 dev int0 metric 256 expires 2132977sec mtu 1500 advmss 1440 metric10 4294967295 
fe80::/64 dev int0 metric 256 expires 2132977sec mtu 1500 advmss 1440 metric10 4294967295 
fe80::/64 dev ext0 metric 256 expires 2132985sec mtu 1500 advmss 1440 metric10 4294967295 
default via fe80::226:88ff:fee2:5d01 dev int0 proto kernel metric 1024 expires 154sec mtu 1500 advmss 1440 metric10 64 
default via fe80::226:88ff:fee2:5d02 dev ext0 proto kernel metric 1024 expires 175sec mtu 1500 advmss 1440 metric10 64 
default via fdc6:3001:8e20:b06::1 dev ext0 metric 1024 expires 2133059sec mtu 1500 advmss 1440 metric10 4294967295 
unreachable default dev lo proto none metric -1 error -101 metric10 255 
ff00::/8 dev int0 metric 256 expires 2132977sec mtu 1500 advmss 1440 metric10 4294967295 
ff00::/8 dev ext0 metric 256 expires 2132985sec mtu 1500 advmss 1440 metric10 4294967295 
unreachable default dev lo proto none metric -1 error -101 metric10 255

在上面的輸出，並路由的訂貨指示其中路由查找的順序？或者「hoplimit」（最後一列）是否會影響查找的順序？ 'hoplimit'和'metric'之間有什麼區別，以及哪兩個影響查找順序？IPv6路由查找順序

謝謝！

來源

2012-04-04 Maddy

問這個問題的具體原因是，當與服務器（其路由如上所述）在同一子網中的客戶端啓動到它的連接時，服務器以網關的目標地址（fdc6：3001： 8e20：9ce9 :: 1），而不是直接與客戶交談。但是，當我刪除默認網關時，連接將通過服務器。 – Maddy 2012-04-04 11:45:25

當我再次添加路由時，通常會再次顯示在頂部，並阻止再次連接。對於子網的情況，不應該爲路線考慮最佳匹配（在本例中爲fdc6：3001：8e20：9ce9 ::/64）？有什麼想法嗎？ – Maddy 2012-04-04 11:49:25

路由首先按最長匹配查找。所以如果有一個/ 64路由，一個/ 48路由和一個默認路由（它是/ 0），它們都與數據包的目的地匹配，那麼將使用/ 64路由，其他路由將被忽略。

實施例：給定的FDC6目的地：3001：8e20：9ce9：1：2：3：4和以下路線：
```
default via fdc6:3001:8e20:9ce9::1 dev int0 metric 1024 expires 2133437sec mtu 1500 advmss 1440 metric10 4294967295 
fdc6:3001:8e20:9ce9::/64 dev int0 metric 256 expires 2132977sec mtu 1500 advmss 1440 metric10 4294967295 
```
的/ 64路由將總是被選擇。

這是儘管您的意見，否則暗示。你在評論中描述的內容不應該發生。請提供有問題的數據包的確切源和目標IP地址以及源和目標MAC地址，以進一步診斷此問題。
如果有多條到目的地的路由具有相同的前綴長度，那麼首選具有最佳指標的路由。

您的路由表中沒有任何示例，其中關係按指標中斷。您需要具有相同目的地和前綴長度但不同指標的路線。
如果仍有多個路由，則會在每個可用路徑上進行負載平衡。

hoplimit在路由查找過程中根本沒有使用。它用於在選擇路由之後設置本地發出的傳出數據包的跳數限制。

來源

2012-04-04 14:28:59 Celada

客戶端數據包詳細信息：源地址：fdc6：3001：8e20：b06：dd9c：57d1：8240：8caa目標地址：fdc6：3001：8e20：b06 :: 171 - 對應的MAC地址：00：50：56：86： 07：94和00：18：7d：1c：a9：71。服務器數據包詳細信息：源地址：fdc6：3001：8e20：b06 :: 171目標地址：fdc6：3001：8e20：b06：dd9c：57d1：8240：8caa - MAC地址：00：18：7d：1c：a9： 71和00：26：88：e2：5d：02。服務器正在將數據包發送到屬於網關的MAC地址00：26：88：e2：5d：02。 – Maddy 2012-04-05 04:24:13

奇怪。服務器上的ip route get fdc6：3001：8e20：b06：dd9c：57d1：8240：8caa'的輸出是什麼？ – Celada 2012-04-05 14:20:49

$/usr/sbin/ip route get fdc6：3001：8e20：b06：dd9c：57d1：8240：8caa fdc6：3001：8e20：b06：dd9c：57d1：8240：8caa via fdc6：3001：8e20：b06： dd9c：57d1：8240：8caa dev ext0 src fdc6：3001：8e20：b06 :: 171 metric 0 cache mtu 1500 advmss 1440 metric10 4294967295 – Maddy 2012-04-05 15:53:47

IPv6的路由查找與傳統的IPv4沒有根本的區別。

IP堆棧將找到最匹配目標IP（即最長前綴）並具有最低度量的路由。

跳數限制不會影響路由決策。度量指示路線的「成本」。它應該根據到目的地的跳數以及路由的帶寬，延遲，價格等來設置。跳數限制僅用於預先設置IPv6報頭中的跳數限制字段。

來源

2012-04-04 14:34:38

您正在看到重定向ICMP消息的效果。

說ip -6 route flush cache使您的路由再次工作。

說sysctl -w net.ipv6.conf.all.accept_redirects=0忽略未來的重定向。

最有可能的原因是啓動/重新啓動時路由不完整的網關。您可能想要告訴該系統不要發送重定向數據包。

來源

2015-08-05 20:36:59

IPv6路由查找順序

回答

相關問題