瞭解ICMP重新導向訊息
簡介
本文件說明網際網路控制訊息通訊協定 (ICMP) 封包重新導向功能。
必要條件
需求
思科建議您瞭解以下主題：
- Nexus 7000 平台架構
- Cisco NX-OS 軟體設定
- 如要求建議 (RFC) 792 中記錄的網際網路控制訊息通訊協定
採用元件
本文中的資訊係根據以下軟體和硬體版本：
- Nexus 7000
- Cisco NX-OS 軟體
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。
背景資訊
本文件將討論網際網路控制訊息通訊協定 (ICMP) 提供的封包重新導向功能。 本文件說明網路中 ICMP 重新導向訊息的存在通常有何意義，以及如何才能縮減導致產生 ICMP 重新導向訊息之網路狀況的相關負面影響。
ICMP 重新導向訊息
RFC 792 網際網路控制訊息通訊協定中透過此範例說明 ICMP 重新導向功能：
在此情況下，閘道會將重新導向訊息傳送到主機
G1 閘道從其所連接網路上的主機接收到網際網路資料包。閘道 G1 會檢查其路由表，並在前往資料包網際網路目的地網路 X 的路由上，取得下一個閘道 G2 的位址。
如果 G2 與資料包的網際網路來源位址所識別的主機位在相同網路上，就會將重新導向訊息傳送到該主機。重新導向訊息會建議主機將其網路 X 的流量直接傳送到閘道 G2，因為這是前往目的地較短的路徑。
閘道會將原始資料包資料轉送到其網際網路目的地。
此場景顯示在圖1中。主機和兩個路由器G1和G2連線到共用乙太網網段，且在同一網路10.0.0.0/24中具有IP地址
圖 1 - 多點乙太網路中的 ICMP 重新導向
多點乙太網路中的 ICMP 重新導向
主機的IP地址為10.0.0.100。主機路由表有一個預設路由條目，該條目指向路由器G1的IP地址10.0.0.1作為預設網關。將流量轉送至目的地網路 X 時，路由器 G1 會使用路由器 G2 的 IP 位址 10.0.0.2 作為其下一個躍點。
以下是主機將封包傳送到目的地網路 X 時，會發生的情況：
1. IP 位址為 10.0.0.1 的閘道 G1 從其連線之網路上的主機 10.0.0.100 收到資料封包。
2. 閘道 G1 會檢查其路由表，並在前往資料封包之目的地網路 X 的路由上，取得下一個閘道 G2 的 IP 位址 10.0.0.2。
3.如果G2和IP資料包的源地址所標識的主機位於同一網路中，則會向主機傳送ICMP重定向消息。ICMP重定向消息建議主機將網路X的流量直接傳送到網關G2，因為這是通往目標的較短路徑。
4. 網關G1將原始資料包轉發到其目的地。
視主機組態而定，它可以選擇忽略 G1 傳送的 ICMP 重新導向訊息。但是，如果主機使用 ICMP 重新導向訊息來調整其路由快取，並開始將後續資料封包直接傳送到 G2，則在這種情況下會實現以下優點
- 最佳化通過網路的資料轉發路徑；流量更快地到達目的地。
- 降低網路資源使用率，例如頻寬和路由器 CPU 負載。
圖 2 - 安裝在主機路由快取中的下一個躍點 G2
安裝在主機路由快取中的下一個躍點 G2
如圖 2 所示，在主機針對具有 G2 的網路 X 建立路由快取項目作為其下一個躍點後，網路中就會出現以下優點：
- 交換器和路由器 G1 之間連結上的頻寬使用率在兩個方向均會降低。
- 路由器 G1 上的 CPU 使用率會降低，因為從主機到網路 X 的流量不再經過此節點。
- 主機和網路 X 之間的端對端網路延遲獲得改善。
若要瞭解 ICMP 重新導向機制的重要性，請記住：早期的網際網路路由器實作主要依靠 CPU 資源來處理資料流量。因此，當時需要減少任何單一路由器必須處理的流量，並將特定流量抵達目的地的過程中必須經過的路由器躍點數量，也一併減至最少。同時，第 2 層轉送（又稱為交換）主要是實作在自訂的特殊應用積體電路 (ASIC) 中，而且從轉送效能的觀點來看，與第 3 層轉送（又稱為路由）比較起來相對便宜，而且也是在通用處理器中完成。
新世代的 ASIC 可以進行第 2 層和第 3 層封包轉送。在硬體中執行第 3 層表格查詢，有助於降低與路由器處理封包相關的效能成本。此外，在將第 3 層轉送功能整合至第 2 層交換器（現在稱為第 3 層交換器）之後，會使封包轉送作業更有效率。這消除了對單臂路由器（亦稱為單線路由器）設計選項的需求，並避免了與此類網路組態相關的限制。
映像3建立在映像1中的場景之上。現在，最初由兩個獨立的節點（交換機和路由器G1）提供的第2層和第3層功能整合到單個第3層交換機（如Nexus 7000系列平台）中。
圖 3 - 第 3 層交換器取代了單臂路由器組態
第 3 層交換器取代了單臂路由器組態
以下是主機將封包傳送到目的地網路 X 時，會發生的情況：
1. IP 位址為 10.0.0.1 的閘道 L3 交換器從其連線之網路的主機 10.0.0.100 接收資料封包。
2. 閘道 L3 交換器會檢查其路由表，並在前往資料封包之目的地網路 X 的路由上，取得下一個閘道 G2 的位址 10.0.0.2。
3.如果G2和IP資料包的源地址所標識的主機位於同一網路中，則會向主機傳送ICMP重定向消息。ICMP重定向消息建議主機將網路X的流量直接傳送到網關G2，因為這是通往目標的較短路徑。
4. 網關將原始資料包轉發到其目的地。
第 3 層交換器現在可以在 ASIC 層級執行第 2 層與第 3 層封包轉送，如此可以兼具 ICMP 重新導向功能的兩項優點。首先，透過網路改善延遲；其次，實現減少網路資源使用率的目標，並且不再需要留意多點乙太網路區段中的路徑最佳化技巧。
但是，在第 3 層介面上啟用 ICMP 重新導向功能後，透過多點乙太網路區段進行次佳轉送仍然有潛在的效能瓶頸，即使是出於其他原因（如本文件稍後的 Nexus 平台考量事項一節所述）亦然。
透過乙太網路的次佳路徑
內部閘道通訊協定 (IGP)（例如開放式最短路徑優先 (OSPF) 和思科增強型內部閘道路由通訊協定 (EIGRP)）的設計是在路由器之間同步路由資訊，並在所有網路節點上提供遵守此類資訊之一致且可預測的封包轉送行為。例如，使用多點乙太網路時，如果區段上的所有第 3 層節點都使用相同的路由資訊，並在到達目的地的相同出口點上達成共識，那麼在此類網路間進行次佳轉送的情況就會很少發生。
若要瞭解導致次佳轉送路徑的原因，請記住：第 3 層節點會相互獨立地做出封包轉送決定。也就是說，路由器 B 做出的封包轉送決定，不會取決於路由器 A 做出的封包轉送決定。這是疑難排解透過 IP 網路轉送封包的問題時要記住的關鍵原則之一，也是調查多點乙太網路中次佳轉送路徑時要牢記的重點。
如前面所述，在所有路由器都依賴單一動態路由通訊協定在端點之間傳遞流量的網路中，必然不會發生透過多點乙太網路區段進行次佳轉送的情況。然而，在現實的網路中，經常會發現各種資料包路由和轉發機制的組合。例如，各種IGP、靜態路由和基於策略的路由。這些功能通常會一起使用，以透過網路實現所需的流量轉送。
雖然結合使用這些機制有助於微調流量並滿足特定網路設計的需求，但此類機制會忽視結合使用這些工具在多點乙太網路中可能產生的副作用，這可能會導致整體網路效能下降。
靜態路由
為了說明此情況，請考慮圖4中的場景。路由器A具有到網路X的靜態路由，路由器B是其下一跳。同時，路由器 B 將路由器 C 當作前往網路 X 之靜態路由的下一個躍點。
圖 4 - 採用靜態路由的次佳路徑
採用靜態路由的次佳路徑
流量透過路由器 A 進入此網路、透過路由器 C 離開並最終傳遞到目的地網路 X 的期間，封包在到達目的地的途中必須經過此 IP 網路兩次。這不是網路資源的有效利用方式。反之，如果將封包從路由器 A 直接傳送到路由器 C 會取得相同的結果，而且耗用的網路資源更少。
原則型路由
原則型路由 (PBR) 是另一種可能會導致透過乙太網路使用次佳路徑的機制。但是，與靜態或動態路由不同，PBR不在路由表級別運行。相反，它直接在交換機硬體中程式設計流量重定向訪問控制清單(ACL)。因此，對於選定的流量流，入口線卡上的資料包轉發查詢會繞過通過靜態或動態路由獲得的路由資訊。
在圖4中，路由器A和路由器B使用其中一個動態路由協定交換有關目的網路X的路由資訊。兩者都同意路由器B是此網路的最佳下一跳。
但是，由於路由器 B 上的 PBR 組態會覆寫從路由通訊協定接收到的路由資訊，並將路由器 C 設定為網路 X 的下一個躍點，因此會滿足觸發 ICMP 重新導向功能的條件，封包也會傳送到路由器 B 的 CPU 進行進一步處理。
點對點連結上的 ICMP 重新導向
到目前為止，本文件指的是連接三個（或更多）第 3 層節點的乙太網路，因此稱為多點乙太網路。但是請注意，點對點乙太網路連結上也可能會產生 ICMP 重新導向訊息。
考慮映像5上的場景。路由器A使用靜態預設路由將流量傳送到路由器B，而路由器B具有指向路由器A的網路X的靜態路由。
圖 5 - 點對點連結上的 ICMP 重新導向
採用靜態路由的次佳路徑
將小型使用者環境連線到服務供應商網路時，此設計選項（也稱為單宿連線）是熱門的選擇。在這裡，路由器 B 是供應商邊緣 (PE) 裝置，而路由器 A 是使用者邊緣 (CE) 裝置。
請注意，一般的 CE 組態包含將靜態路由匯聚至指向 Null0 介面的使用者 IP 位址區塊。對於採用靜態路由的單宿 CE-PE 連線選項，此組態是建議的最佳作法。但是，在此範例中，請假設不存在此類組態。
假設路由器 A 已失去對網路 X 的連線，如圖所示。來自使用者網路 Y 或遠端網路 Z 的封包嘗試進入網路 X 時，路由器 A 和 B 會互相退回流量，從而使每個封包中的 IP 存留時間欄位減少，直到其值達到 1，也就是封包無法進一步路由的時間點為止。
當前往網路 X 的流量在 PE 與 CE 路由器之來回跳轉時，會不必要地大幅提高 CE-PE 連結頻寬使用率。如果在點對點 PE-CE 連線的一端或兩端同時啟用 ICMP 重新導向，則問題會更加嚴重。在這種情況下，資料流中所有導向網路 X 的封包都會在各自路由器的 CPU 中經過多次處理，以協助產生 ICMP 重新導向訊息。
Nexus 平台考量事項
在第3層介面上啟用ICMP重新導向且傳入資料封包使用此介面來輸入和輸出第3層交換器時，會產生ICMP重新導向訊息。雖然第3層封包轉送在Cisco Nexus 7000平台上的硬體中完成，但交換器CPU仍負責建立ICMP重新導向訊息。若要執行此操作，Nexus 7000監督器模組上的CPU需要取得其透過網段的路徑可最佳化的流量的IP位址資訊。這就是輸入線路卡將資料封包傳送到監督器模組背後的原因。
如果 ICMP 重新導向訊息的接收方予以忽略，並繼續將資料流量轉送到已啟用 ICMP 重新導向之 Nexus 交換器的第 3 層介面，則會對每個資料封包觸發 ICMP 重新導向產生程序。
在線路卡層級，該程序會以硬體轉送例外的形式開始。線路卡模組無法成功完成封包轉送作業時，ASIC 會產生例外。在這種情況下，就必須將資料封包傳送到監督器模組以進行正確的封包處理。
監督器模組上的 CPU 對來源傳送 ICMP 重新導向訊息之後，就會透過輸出線路卡模組將資料封包轉送到下一個躍點，以完成例外處理。
Nexus 7000 監督器模組使用功能強大、能夠處理大量流量的 CPU 處理器，而該平台的設計能夠在線路卡層級處理大部分資料流量，不需要在封包轉送程序中使用監督器的 CPU 處理器。這讓 CPU 能夠專注於其核心工作，將封包轉送作業留給線路卡上的專用硬體引擎處理。
在穩定的網路中，資料包轉發異常（如果發生）預計將以相當低的速率發生。使用此假設，它們可以由Supervisor CPU處理，而不會對其效能產生重大影響。另一方面，使用 CPU 處理發生率極高的封包轉送例外，可能會對整個系統的穩定性和回應能力造成負面影響。
Nexus 7000 平台設計提供多種機制來防止交換器 CPU 不受大量流量影響。這些機制會在系統的不同點執行。線路卡層級有硬體速率限制工具和控制平面管制 (CoPP) 功能Policing這兩項功能皆可設定流量速率臨界值，能夠有效地控制從每個線路卡模組轉送到監督器的流量。
這些保護機制會優先考慮對網路穩定性和交換器可管理性至關重要之各種控制通訊協定（例如 OSPF、BGP 或 SSH）的流量，同時積極過濾對交換器控制平面管制功能不甚重要的流量類型。如果因為封包轉送例外而將大部分資料流量轉送到 CPU，就會受到此類機制的嚴格管制。
雖然硬體速率限制工具和 CoPP 機制提供交換器控制平面的穩定性，且強烈建議一律加以啟用，但它們可能是導致資料封包捨棄、傳輸延遲以及網路上整體應用程式效能不佳的主要原因之一。policing這就是為什麼務必要瞭解流量流經網路所採取的路徑，也務必使用工具來監控可以和/或預期使用 ICMP 重新導向功能之網路設備等的原因。
監控與診斷流量工具
show ip traffic
Cisco IOS 和 Cisco NX-OS 軟體均提供方法可檢查 CPU 所處理的流量統計資料。這可以使用 命令來完成。show ip traffic此命令可用來檢查第 3 層交換器或路由器之 ICMP 重新導向訊息的接收和/或產生。
Nexus7000#show ip traffic | begin ICMP
ICMP Software Processed Traffic Statistics
------------------------------------------
Transmission:
Redirect: 1000, unreachable: 0, echo request: 0, echo reply: 0,
<output omitted for brevity>
ICMP originate Req: 0, Redirects Originate Req: 1000
Originate deny - Resource fail: 0, short ip: 0, icmp: 0, others: 0
Reception:
Redirect: 0, unreachable: 0, echo request: 0, echo reply: 0,
<output omitted for brevity>
Nexus7000#
執行 命令幾次，並檢查 ICMP 重新導向計數器是否有所增加。show ip traffic
Ethanalyzer
Cisco NX-OS 軟體有一個內建工具可擷取於交換器 CPU 的流量，稱為 Ethanalyzer。flowing
圖6顯示的場景與圖3中的場景相似。此處網路X由192.168.0.0/24網路替換。
圖 6 - 執行 Ethanalyzer 擷取
執行 Ethanalyzer 擷取
主機10.0.0.100向目標IP地址192.168.0.1傳送連續ICMP回應請求流。該主機使用Nexus 7000交換機的交換機虛擬介面(SVI)10作為其到遠端網路192.168.0.0/24的下一跳。為了進行演示，該主機配置為忽略ICMP重定向消息。
使用此後續命令可擷取 Nexus 7000 CPU 接收和傳送的 ICMP 流量：
Nexus7000#ethanalyzer local interface inband capture-filter icmp limit-captured-frames 1000
Capturing on inband
2018-09-15 23:45:40.124077 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.124477 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.124533 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.126344 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.126607 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.126655 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.128348 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.128611 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.128659 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.130362 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.130621 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.130669 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.132392 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.132652 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.132700 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.134347 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.134612 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.134660 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.136347 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.136598 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.136645 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.138351 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.138607 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.138656 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
...前面輸出中的時間戳表明此示例中突出顯示的三個資料包是同時捕獲的，即2018-09-15 23:45:40.128。接下來是此資料包組的每個資料包細分
- 第一個封包是輸入資料封包，此範例為 ICMP 回應要求。
2018-09-15 23:45:40.128348 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
- 第二個封包是閘道所產生的 ICMP 重新導向封包。該封包會傳送回主機。
2018-09-15 23:45:40.128611 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
- 第三個封包是由 CPU 路由之後在輸出方向擷取的資料封包。儘管先前並未顯示，但此封包的 IP TTL 遞減，總和檢查碼也重新計算。
2018-09-15 23:45:40.128659 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
在許多不同類型和流量的大型 Ethanalyzer 擷取內容間導覽時，可能難以將 ICMP 重新導向訊息與對應至訊息的資料流量建立關聯。
在這些情況下，請專注於 ICMP 重新導向訊息以擷取有關次佳轉送流量的資訊。ICMP重定向消息包括Internet報頭加上原始資料包資料的前64位。資料包的源使用此資料將消息與相應進程匹配。
使用 Ethanalyzer 封包擷取工具搭配 detail 關鍵字可顯示 ICMP 重新導向訊息的內容，並尋找次佳轉送之資料流量的 IP 位址資訊。
Nexus7000#ethanalyzer local interface inband capture-filter icmp limit-captured-frames 1000 detail
...
Frame 2 (70 bytes on wire, 70 bytes captured)
Arrival Time: Sep 15, 2018 23:54:04.388577000
[Time delta from previous captured frame: 0.000426000 seconds]
[Time delta from previous displayed frame: 0.000426000 seconds]
[Time since reference or first frame: 0.000426000 seconds]
Frame Number: 2
Frame Length: 70 bytes
Capture Length: 70 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:icmp:ip:icmp:data]
Ethernet II, Src: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf), Dst: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)
Destination: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)
Address: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf)
Address: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 10.0.0.1 (10.0.0.1), Dst: 10.0.0.100 (10.0.0.100)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 56
Identification: 0xf986 (63878)
Flags: 0x00
0.. = Reserved bit: Not Set
.0. = Don't fragment: Not Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 255
Protocol: ICMP (0x01)
Header checksum: 0xadd9 [correct]
[Good: True]
[Bad : False]
Source: 10.0.0.1 (10.0.0.1)
Destination: 10.0.0.100 (10.0.0.100)
Internet Control Message Protocol
Type: 5 (Redirect)
Code: 1 (Redirect for host)
Checksum: 0xb8e5 [correct]
Gateway address: 10.0.0.2 (10.0.0.2)
Internet Protocol, Src: 10.0.0.100 (10.0.0.100), Dst: 192.168.0.1 (192.168.0.1)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 84
Identification: 0xf986 (63878)
Flags: 0x00
0.. = Reserved bit: Not Set
.0. = Don't fragment: Not Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 254
Protocol: ICMP (0x01)
Header checksum: 0xa8ae [correct]
[Good: True]
[Bad : False]
Source: 10.0.0.100 (10.0.0.100)
Destination: 192.168.0.1 (192.168.0.1)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0 ()
Checksum: 0x02f9 [incorrect,shouldbe 0xcae1]
Identifier: 0xa01d
Sequence number: 36096 (0x8d00)
...
停用 ICMP 重新導向
如果網路設計會要求流量從進入交換器或路由器的相同第 3 層介面路由出去，則假如您停用與其對應的第 3 層介面上的 ICMP 重新導向功能，就能防止流量經過 CPU 進行路由。
事實上，對於大多數網路而言，在所有第 3 層介面（也就是乙太網路介面等實體介面以及連接埠通道和 SVI 介面等虛擬介面）上主動停用 ICMP 重新導向是一個好做法。使用 Cisco NX-OS 介面層級命令可停用第 3 層介面上的 ICMP 重新導向。no ip redirects若要驗證 ICMP 重新導向功能是否已停用：
- 確保no ip redirects命令已新增到介面配置。
Nexus7000#show run interface vlan 10 interface Vlan10
no shutdown no ip redirects ip address 10.0.0.1/24
- 確認介面上的 ICMP 重新導向狀態顯示為已停用。
Nexus7000#show ip interface vlan 10 | include redirects IP icmp redirects: disabled
- 確認將介面組態從交換器監督器推送到一或多個線路卡的 Cisco NX-OS 軟體元件，已將 ICMP 重新導向將啟用/停用旗標設定為 0。
Nexus7000#show system internal eltm info interface vlan 10 | i icmp_redirect per_pkt_ls_en = 0, icmp_redirect = 0, v4_same_if_check = 0
- 確認在一或多個線路卡上特定第 3 層介面的 ICMP 重新導向啟用/停用旗標已設定為 0。
Nexus7000#attach module 7
Attaching to module 7 ...
To exit type 'exit', to abort type '$.'
Last login: Wed Sep 15 23:56:25 UTC 2018 from 127.1.1.1 on pts/0
module-7#
!--- Optionally, jump to non-admin Virtual Device Context (VDC) if verification needs to be done in one of the custom VDCs
module-7#vdc 6
module-7#show system internal iftmc info interface vlan 10 | include icmp_redirect
icmp_redirect : 0x0 ipv6_redirect : 0x1
摘要
如 RFC 792 中所述，ICMP 重新導向機制旨在最佳化透過多點網路區段的轉送路徑。在Internet剛開始時，此類最佳化有助於保護昂貴的網路資源，如鏈路頻寬和路由器的CPU週期。隨著網路頻寬變得更加經濟實惠，並且相對較慢的基於CPU的資料包路由演變為專用硬體ASIC中更快速的第3層資料包轉發，通過多點網段傳輸最佳資料的重要性降低了。預設情況下，ICMP重定向功能在每個第3層介面上啟用。但是，它試圖通知多點乙太網段上的網路節點最佳轉發路徑的嘗試並不總是由網路人員理解和執行。在結合使用各種轉發機制（如靜態路由、動態路由和基於策略的路由）的網路中，如果您保留ICMP重定向功能並且未正確監控，則可能導致不必要地使用傳輸節點CPU來處理生產流量。因此，這會對生產流量和網路基礎架構的控制平面穩定性造成重大影響。
對於大多數網路，普遍認為在網路基礎架構中的所有第 3 層介面上主動停用 ICMP 重新導向功能是一種好作法。有更好的轉送路徑可到達多點網路區段時，這有助於防止在第 3 層交換器和路由器的 CPU 中處理生產資料流量。
修訂記錄
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
4.0 |
14-May-2025
|
已更新格式。 |
3.0 |
31-Oct-2023
|
更新的品牌推廣要求、格式和參與者清單。 |
2.0 |
22-Sep-2022
|
重新認證 |
1.0 |
17-Oct-2018
|
初始版本 |
意見