瞭解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和由資料包的Internet源地址標識的主機位於同一網路中，則會向主機傳送重定向消息。重定向消息建議主機將網路X的流量直接傳送到網關G2，因為這是通往目的地的較短路徑。
網關將原始資料包資料轉發到其Internet目標。
此案例如圖1所示。 主機和兩台路由器G1和G2連線到共用乙太網網段，並在同一網路10.0.0.0/24中具有IP地址
映像1 — 多點乙太網中的ICMP重定向
多點乙太網中的ICMP重定向
主機的IP地址為10.0.0.100。主機路由表有一個預設路由條目，該條目指向路由器G1的IP地址10.0.0.1作為預設網關。路由器G1在將流量轉發到目的網路X時，使用路由器G2的IP地址10.0.0.2作為下一跳。
這就是主機將封包傳送到目的地網路X時發生的情況：
1. IP地址為10.0.0.1的網關G1從它連線的網路中的主機10.0.0.100接收資料包。
2.網關G1檢查其路由表並獲取下一個網關G2的IP地址10.0.0.2，該路由到資料包目的網路X。
3.如果G2和IP資料包的源地址所標識的主機位於同一網路中，則會向主機傳送ICMP重定向消息。 ICMP重定向消息建議主機將網路X的流量直接傳送到網關G2，因為這是通往目的地的較短路徑。
4.網關G1將原始資料包轉發到其目的地。
根據主機配置，它可以選擇忽略G1向其傳送的ICMP重定向消息。但是，如果主機使用ICMP重定向消息來調整其路由快取並開始將後續資料包直接傳送到G2，則在此場景中可實現這些優勢
- 最佳化通過網路的資料轉發路徑；流量更快地到達目的地。
- 減少網路資源利用率，例如頻寬和路由器CPU負載。
圖2 — 安裝在主機路由快取中的下一跳G2
在主機路由快取中安裝下一跳G2
如圖2所示，在主機為G2作為其下一跳的網路X建立路由快取條目後，網路中即可看到以下優點：
- 交換機和路由器G1之間鏈路的頻寬利用率在兩個方向上都有所下降。
- 由於從主機到網路X的流量不再流經此節點，路由器G1上的CPU使用率降低。
- 主機與網路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交換機檢查其路由表，獲取下一網關G2在通往資料包目的網路X的路由上的地址10.0.0.2。
3.如果G2和IP資料包的源地址所標識的主機位於同一網路中，則會向主機傳送ICMP重定向消息。 ICMP重定向消息建議主機將網路X的流量直接傳送到網關G2，因為這是通往目的地的較短路徑。
4.網關將原始資料包轉發到其目的地。
第3層交換機現在能夠在ASIC級別同時執行第2層和第3層資料包轉發，因此可以推斷ICMP重定向功能的兩個優點。第一，改善通過網路的延遲；第二，降低網路資源的利用率，使得多點乙太網段不再需要過多關注路徑最佳化技術。
但是，由於第3層介面上啟用了ICMP重定向功能，通過多點乙太網網段的次優轉發仍會存在潛在的效能瓶頸，儘管原因不同，如本文檔後面的Nexus平台注意事項一節所述。
通過乙太網路的次最佳路徑
內部閘道通訊協定(IGP)(例如開放最短路徑優先(OSPF)和Cisco增強型內部閘道路由通訊協定(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，此時無法進一步路由資料包。
儘管到Network X的流量在PE和CE路由器之間來回反彈，但CE-PE鏈路頻寬利用率卻顯著增加（而且不必）。如果在點對點PE-CE連線的一端或兩端啟用ICMP重定向，則問題會更嚴重。在此案例中，導向網路X的流量中的每個封包會在每個路由器的CPU中處理多次，以協助產生ICMP重新導向訊息。
Nexus平台注意事項
當第3層介面上啟用ICMP重新導向且傳入資料封包使用此介面來輸入和輸出第3層交換器時，會產生ICMP重新導向訊息。 雖然第3層封包轉送是在Cisco Nexus 7000平台上的硬體中完成的，但構造ICMP重新導向訊息仍由交換器CPU負責。 為此，Nexus 7000 Supervisor模組上的CPU需要獲取流的IP地址資訊，該流通過網段的路徑可以最佳化。這是入口線卡向Supervisor模組傳送資料封包之後發生的原因。
如果ICMP重定向消息的收件人忽略該消息並繼續將資料流量轉發到已啟用ICMP重定向的Nexus交換機的第3層介面，則會為每個資料包觸發ICMP重定向生成過程。
線上卡級別，該過程以硬體轉發異常的形式啟動。當線卡模組無法成功完成資料包轉發操作時，在ASIC上引發異常。在這種情況下，資料包需要傳送到Supervisor模組以進行正確的資料包處理。
Supervisor模組上的CPU向源傳送ICMP重定向消息後，通過出口線卡模組將資料包轉發到下一跳來完成異常處理。
雖然Nexus 7000 Supervisor模組使用功能強大的CPU處理器來處理大量流量，但該平台的設計可線上卡級別處理大部分資料流量，而無需在資料包轉發過程中使用Supervisor CPU處理器。這允許CPU集中處理其核心任務，並將資料包轉發操作保留給線卡上的專用硬體引擎。
在穩定的網路中，如果發生資料包轉發異常，預計將以相當低的速率發生。 使用此假設，它們可以由Supervisor CPU處理，而不會對其效能產生重大影響。另一方面，對於處理以非常高速率發生的資料包轉發異常的CPU，可能會對整體系統穩定性和響應性產生負面影響。
Nexus 7000平台設計提供多種機制來保護交換機CPU免受大量流量的影響。這些機制在系統的不同點實施。線上卡級別，有硬體速率限制器和控制平面 Policing (CoPP)功能。二者都設定了流量速率閾值，有效控制從每個線卡模組轉發到Supervisor的流量。
這些保護機制優先使用對網路穩定性和交換機可管理性至關重要的各種控制協定（例如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#
運行 show ip traffic 命令並檢查ICMP重定向計數器是否增加。
Ethanalyzer
Cisco NX-OS軟體具有捕獲流量的內建工具 flowing 交換機CPU之間的連線，稱為Ethanalyzer。
圖6顯示的場景與圖3中的場景相似。網路X由192.168.0.0/24網路替換。
影象6 — 運行Ethanalyzer捕獲
運行Ethanalyzer捕獲
主機10.0.0.100將連續的ICMP回應請求流傳送到目標IP地址192.168.0.1。主機使用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回應(ping)請求
- 第二個資料包是由網關生成的ICMP重定向資料包。此封包會傳送回主機。
2018-09-15 23:45:40.128611 10.0.0.1 -> 10.0.0.100 ICMP重新導向（主機重新導向）
- 第三個資料包是CPU路由後在出口方向捕獲的資料包。雖然之前未顯示，此封包的IP TTL會遞減並重新計算總和檢查碼。
2018-09-15 23:45:40.128659 10.0.0.100 -> 192.168.0.1 ICMP回應(ping)請求
當您瀏覽包含許多不同型別和流量的資料包的大型Ethanalyzer捕獲時，很難將ICMP重定向消息與相應的資料流量相關聯。
在這些情況下，請聚焦ICMP重定向消息以檢索有關未以最佳狀態轉發的流量的資訊。ICMP重定向消息包括Internet報頭加上原始資料包資料的前64位。 此資料由資料包的源使用，以將郵件與相應的進程匹配。
使用帶有detail關鍵字的Ethanalyzer封包擷取工具以顯示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層介面上主動禁用ICMP重定向，物理介面（如乙太網介面）和虛擬介面（如埠通道和SVI介面）。使用 no ip redirects Cisco NX-OS介面級命令禁用第3層介面上的ICMP重定向。驗證ICMP重新導向功能是否已停用：
- 確保
no ipredirects命令被新增到介面配置。
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，該元件將介面配置從交換機Supervisor推送到多個線卡之一。
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層資料包轉發，通過多點網段傳輸最佳資料的重要性降低。 預設情況下，每個第3層介面都會啟用ICMP重新導向功能。但是，它嘗試向多點乙太網網段上的網路節點通知最佳轉發路徑的嘗試並不總是被網路人員理解並執行。 在結合使用各種轉送機制（例如靜態路由、動態路由和基於策略的路由）的網路中，如果您保留ICMP重新導向功能且未正確監控，則可能會導致不必要地使用傳輸節點CPU來處理生產流量。這反過來又會對網路基礎設施的生產流量流和控制平面穩定性造成重大影響。
對於大多數網路，主動停用網路基礎架構中所有第3層介面的ICMP重新導向功能是很好的作法。這有助於防止在存在通過多點網段的更佳轉發路徑時，在第3層交換機和路由器的CPU中處理生產資料流量的情況。
修訂記錄
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
3.0 |
31-Oct-2023 |
更新的品牌推廣要求、格式和參與者清單。 |
2.0 |
22-Sep-2022 |
重新認證 |
1.0 |
17-Oct-2018 |
初始版本 |
意見