Catalyst 6500平台上的高CPU利用率配置指南

簡介

本檔案介紹如何在Cisco Catalyst 6500系列平台上使用Web快取通訊協定(WCCP)。

WCCP最初被設計為一種擷取Web流量(HTTP)並將其轉發到本地快取裝置的方法，在本地快取裝置可以將其從本地位置提供給客戶端，並節省昂貴的WAN頻寬。

從網路使用者的角度來看，WCCP是透明的，因為它用於網路級別，使用者無需進行任何特殊配置，即可標識穿越第3層(L3)裝置的網路流量並將其重定向到本地快取裝置。雖然WCCP最初是為網路流量設計的，但透明重定向方法已成為非常有用的機制，可以解決在低流量鏈路上使用高容量內容的其他問題。因此，在更高版本的WCCP中新增了額外的協定支援。這些附加技術包括HTTP、HTTPS、FTP、影片流等協定和檔案快取技術，例如通用網際網路檔案系統(CIFS)。 這些技術支援較新的思科解決方案和平台，例如廣域檔案服務(WAFS)、廣域應用程式服務(WAAS)、應用導向型網路(AON)，以及應用程式和內容網路軟體(ACNS)的增強功能。

隨著企業實施基於影片的通訊和培訓、即時影片和點播影片等最新的生產力工具，WCCP的採用率也在不斷提高。控制成本（如整合的資料中心）的工作使WCCP需要支援額外的、極高的頻寬服務。

由於WCCP在當今內容豐富的網路中的重要性，一些平台（如Catalyst 6500）已經使用WCCP實施了硬體輔助效能，從而降低了協定所需的CPU負載。本文說明如何在Catalyst 6500上部署WCCP，以便最大限度地提高硬體利用率並減少CPU負載。

必要條件

需求

思科建議您瞭解以下主題：

• WCCP
• Cisco Catalyst 6500 系列交換器
• Cisco IOS®^軟體

採用元件

本文中的資訊係根據以下軟體和硬體版本：

• Cisco Catalyst 6500 系列交換器
• 搭載Supervisor引擎2T（原則功能卡4）的Cisco IOS軟體版本12.1(50)SY或更新版本
• 搭載Supervisor Engine 720（原則功能卡3）的Cisco IOS軟體版本12.2(18)SXD1或更新版本

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路正在作用，請確保您已瞭解任何指令可能造成的影響。

WCCP功能概述

通常稱為WCCP的功能實際上涉及三個元件：

1. 僅在路由器或交換機上實現的功能
2. 僅在流量處理實體（例如Web快取）上實現的功能
3. 在雙方實施WCCP

本檔案將檢視以下三個WCCP運作特徵：

1. 指派方法確定選擇哪個WCCP流量以及選擇哪個WCCP裝置作為流量的目的地。WCCP協定支援多個聚集在一起的裝置。
2. 當需要更改流量所經過的正常網路路徑時，重新導向方法會將流量轉發到WCCP裝置。
3. return方法決定在無法服務流量時，如何從WCCP裝置將流量傳送迴路由器。在WCCP裝置為請求提供服務的情況下，資料包將直接返回給請求者。

WCCP和Catalyst 6500

Catalyst 6500監督器引擎2、監督器引擎32和管理器引擎720支援以下WCCP功能和方法：

• WCCP第2版(WCCPv2)
• 基於雜湊的分配方法
• 基於掩碼的分配方法（硬體加速）
• 第3層通用路由封裝(GRE)重新導向方法（在Supervisor Engine 32和Supervisor Engine 720上硬體加速）
• 第2層(L2)重新導向方法（在Supervisor Engine 2、Supervisor Engine 32和Supervisor Engine 720上硬體加速）
• GRE返回方法
• Cisco IOS軟體版本12.2SXH的L2返回方法（Supervisor Engine 2、Supervisor Engine 32和Supervisor Engine 720上硬體加速）

有關這些功能的詳細資訊，請參閱Cisco 6500系列Cisco IOS軟體配置指南12.2SX中的配置WCCP。

WCCP分配方法

WCCP分配確定WCCP協定重定向的流量以及哪個WCCP實體接收重定向的流量。

在路由器的介面和WCCP實體上設定WCCP時，重新導向裝置(Catalyst 6500)需要知道將重新導向哪些流量以及將流量傳送到何處。服務組集群內的WCCP實體都通過WCCP協定與Catalyst 6500通訊；但是，選擇一個WCCP裝置來代表群集，以便控制群集的運行方式（通過分配方法、重定向方法等）。 WCCP裝置和路由器可以協商在服務組中的網路快取之間分發資料包的方法。服務組定義為最多32台路由器和32個WCCP實體之間的多對多關係。協商是按服務組進行的；因此，參與多個服務組的web快取可以針對每個服務組協商不同的分配方法。當前可用的WCCP服務包括：

*在Catalyst 6500中通過應用到入站或出站方向的介面級別命令實施使用者可配置服務。選擇入站或出站的影響將在稍後討論，但入站是首選方法，因為重定向清單可以與WCCP耦合以實現最大的硬體效能。

一旦配置了WCCP，路由器將在WCCP通訊消息中通告服務組所支援的分配方法。沒有此類消息意味著Catalyst 6500僅支援預設基於雜湊的分配方法。

Catalyst 6500和WCCP裝置之間的協商完成後，WCCP指定實體通過WCCP通知Catalyst 6500哪些流量將重定向以及流量將分配給哪個WCCP實體。例如，當有四個以上的WCCP裝置可用時，WCCP實體可以通知Catalyst 6500將所有網路流量從特定子網重定向到服務組中的快取引擎1 - 4。

WCCP有兩種分配方法：

1. 基於雜湊的分配（預設）使用基於軟體的雜湊演算法以及來自WCCP指定裝置的指令，以確定哪個WCCP裝置接收流量。在Supervisor Engine 32或Supervisor Engine 720平台中，NetFlow硬體資源用於應用某種級別的硬體輔助。
2. 基於遮罩的分配利用Catalyst 6500的硬體功能(尤其是存取控制清單(ACL)三重內容可定址記憶體(TCAM))，將流量分配給WCCP實體。這是首選方法。

WCCP服務組中的所有裝置必須使用相同的分配方法。分配方法在WCCP實體上配置並由Catalyst 6500獲取。有關詳細資訊，請參閱WCCP設計建議。

基於雜湊的分配方法詳細資訊

基於雜湊的分配機制依賴於軟體中執行的演算法。為了利用雜湊演算法，將特定流中的第一個資料包從硬體路徑傳送到執行雜湊的軟體路徑。

軟體執行流中各種元件的XOR雜湊，並生成一個雜湊，將流量拆分到各種WCCP實體。雜湊機制確定流量在可用WCCP實體中的分配方式。

雜湊結果被程式設計到硬體NetFlow表中，在該表中轉發該流中的後續資料包。不管WCCP可用於雜湊哪些欄位，都使用完整的五元組。這表示啟用WCCP時，NetFlow進入介面全流模式。這對可能需要NetFlow資源的其他功能有影響。有關詳細資訊，請參閱WCCP缺陷部分。

有關Catalyst 6500上的WCCP的一個常見問題是，「當我啟用WCCP時，為什麼CPU利用率會提高？」 使用基於雜湊的分配時，每個流中初始資料包的基於軟體的處理會給CPU帶來負擔，通常是利用率增加的原因。若使用目前可用的原則功能卡3(PFC3)轉送硬體，如果已將WCCP設定為輸出功能或使用基於雜湊的分配（輸入或輸出），則總是需要某些級別的軟體處理。

使用基於雜湊的分配方法會影響以下功能：

• NetFlow表 - PFC支援的條目數量受到限制，並且流掩碼將更改為整個NetFlow表的介面全流。
• CPU使用率 — 由於每個流中的第一個資料包是軟體交換的，CPU使用率有所上升。
• Performance — 將流量傳送到CPU進行查詢的速率受到限制，以便CPU受到保護。
• NetFlow功能 — 如果NetFlow資源由WCCP使用，則使用NetFlow資源的其他功能可能會受到影響。

基於雜湊的軟體處理分配要求所帶來的限制和影響適用於入口和出口流量。如果網路正經歷非典型流量模式(如拒絕服務(DoS)攻擊)，則對CPU的影響可能會加劇。在典型的攻擊或蠕蟲病毒爆發中，主機傳送的每個資料包都指向新的目標或埠，這會導致每個資料包在軟體中處理。由於WCCP重定向的流量被明確傳送到CPU進行第一個資料包處理，因此保護方法有限。在介面上使用「deny」ACL專案可能會限制傳送到CPU的專案；但是，對於這些型別的攻擊，沒有速率限制器或其他保護措施。

基於掩碼的分配方法詳細資訊

基於遮罩的指派的處理方式不同，取決於是在輸入上設定還是在輸出上設定。

使用基於入口掩碼的分配，在轉發資料包之前將掩碼程式設計到ACL TCAM中，因此不需要NetFlow表和軟體處理。WCCP實體選擇多個雜湊儲存桶，並為每個儲存桶分配地址掩碼和WCCP裝置。一旦分配完成，管理引擎將為每個儲存段程式設計一個TCAM條目和一個硬體鄰接關係，並通過L2重寫將匹配地址掩碼的資料包重定向到關聯的WCCP裝置。

如果將WCCP設定為輸入功能，它可能會在硬體ACL表中使用ACL重新導向鄰接專案。WCCP匹配條目後，會使用適當的鄰接關係來執行L2重寫或GRE封裝。因此，當輸入上使用遮罩分配時，L2重寫（Supervisor Engine 2、Supervisor Engine 32和Supervisor Engine 720）和GRE封裝（僅限Supervisor Engine 32和Supervisor Engine 720）都會在硬體中執行。

如果將WCCP配置為出口功能，則硬體不支援ACL重定向鄰接關係，因為流中的資料包已由系統路由。流的第一個資料包被傳送到軟體進行處理。確定正確的重定向鄰接關係後，會將它程式設計到NetFlow硬體（而不是ACL TCAM）中，其中條目指向執行L2重寫或GRE封裝的鄰接關係。NetFlow硬體將在硬體中重定向流中的後續資料包。

附註：如果將WCCP配置為出口功能，則掩碼分配需要軟體處理，這會抵消基於掩碼的分配方法的任何優點。

在基於掩碼的兩個選項中，只有基於入口掩碼的分配才能為初始資料包和後續資料包實現基於硬體的完全轉發。任何其它選項（例如使用基於雜湊的分配或出口處理）都會導致初始資料包的軟體交換和後續資料包的硬體 — NetFlow交換轉發。

WCCP重新導向方法

WCCP實體（而不是Catalyst 6500）將雜湊表和掩碼/值集指定給Catalyst 6500，因此重定向方法的配置是在該裝置上完成的，而不是在Catalyst 6500交換機上完成的。Catalyst 6500根據與WCCP實體/組的WCCP通訊確定可用的最佳重定向方法。此協商確定重定向流量如何轉發到裝置。有兩種重新導向選項：L3(GRE)和L2（MAC地址重寫）。

使用WCCPv1時，唯一的選項是第3層重新導向，也稱為GRE封裝。使用第3層重新導向，每個WCCP重新導向的封包都會封裝到標有通訊協定型別0x883E的GRE標頭中，其後是四個八位元的WCCP重新導向標頭，接著會傳送到WCCP裝置（例如快取引擎）。

隨著WCCPv2的引入，為了利用Catalyst 6500等硬體交換平台，新增了L2重定向（也稱為加速WCCP重定向）。當WCCP使用L2重定向時，WCCP裝置和Catalyst 6500必須是L2鄰接的（在同一個L2 VLAN內）。 重新導向的第2層流量不使用GRE封裝；相反，MAC目的地址由Catalyst 6500重寫為與L2連線的WCCP實體的地址，並通過正常的硬體交換轉發。

附註：轉發到WCCP裝置的方法可能與WCCP裝置用於將流量傳送回Catalyst 6500的方法不同。WCCP用於協商兩台裝置均支援的轉發和返回方法。請參閱WCCP返回方法。

L3(GRE)轉發方法

WCCP L3操作涉及使用GRE作為封裝方法。重新導向的封包將封裝在GRE標頭中，通訊協定型別為0x883e，並附有4位元組的WCCP重新導向標頭，其中包含相符的服務ID和雜湊桶（僅限WCCPv2）。 使用GRE可以將WCCP客戶端與Catalyst 6500分隔為多個L3（路由）跳。

在此案例中，可用於WCCP重新導向的選項包括：

1. 輸入 — 第3層(GRE)重新導向+雜湊分配；這需要軟體處理。
2. 輸入 — 第3層(GRE)重新導向+遮罩指派；這要求完全的硬體處理，並且僅在Supervisor Engine 32或Supervisor Engine 720上可用。
3. 輸出 — 第3層(GRE)重新導向+雜湊分配；這需要軟體處理。
4. 輸出 — 第3層(GRE)重新導向+遮罩指派；這需要軟體處理。

輸入 — 第3層(GRE)重新導向+雜湊分配

在Supervisor Engine 2上，每個GRE封包都會傳送到多層交換器功能卡(MSFC)以進行處理。由於硬體不支援GRE封裝，MSFC必須同時套用GRE和WCCP標頭，這會強制所有流量進行軟體交換。

使用基於雜湊的分配方法，Supervisor引擎32和Supervisor引擎720轉發軟體中每個流的第一個資料包，以便建立NetFlow表條目。然後將封包封裝在GRE中（初始封包的封裝和轉送在軟體中完成），然後轉送到WCCP裝置。

NetFlow條目的建立會影響CPU利用率，但後續的資料包轉發是在硬體中完成，用於Supervisor Engine 720和Supervisor Engine 32。流量模式（尤其是唯一流的數量）決定了CPU的利用率。如果消耗了Catalyst 6500的NetFlow資源，則會在軟體中轉發所有流量。

Supervisor PFC的NetFlow資源在不同平台上有所不同。目前，最大的NetFlow資源在Supervisor引擎720平台上的PFC-3BXL上可用。

輸入 — 第3層(GRE)重新導向+遮罩指派

在Supervisor Engine 2上，每個GRE封包都會傳送到MSFC以進行處理。由於硬體不支援GRE封裝，MSFC必須同時套用GRE和WCCP標頭，這會強制所有流量進行軟體交換。

使用基於掩碼的分配方法，Supervisor引擎32和Supervisor引擎720會在硬體中轉發初始資料包和後續資料包，因為本地支援GRE，並且掩碼分配使用ACL TCAM硬體進行轉發。

輸出 — L3(GRE)重新導向+雜湊分配

在Supervisor引擎2上，每個資料包都傳送到MSFC進行處理。由於硬體不支援GRE封裝，MSFC必須同時套用GRE和WCCP標頭，這會強制所有流量進行軟體交換。

Catalyst 6500使用Supervisor引擎32和Supervisor引擎720基於雜湊的分配方法，轉發軟體中每個流的初始資料包，以便建立NetFlow表條目。然後將封包封裝在GRE中並轉送到WCCP實體。

NetFlow條目的建立會影響CPU利用率，但後續的資料包轉發是在硬體中完成的。流量模式（尤其是唯一流的數量）決定了CPU的利用率。如果消耗了Catalyst 6500的NetFlow資源，則會在軟體中轉發所有流量。

Supervisor PFC的NetFlow資源在不同平台上有所不同。目前，最大的NetFlow資源在Supervisor引擎720平台上的PFC-3BXL上可用。

輸出 — 第3層(GRE)重新導向+遮罩指派

在Supervisor引擎2上，每個資料包都傳送到MSFC進行處理。由於硬體不支援GRE封裝，MSFC必須同時套用GRE和WCCP標頭，這會強制所有流量進行軟體交換。

在Supervisor引擎32和Supervisor引擎720採用基於掩碼的分配方法中，每個流的第一個資料包進行軟體交換，以建立NetFlow表條目。沒有一個管理引擎支援出口ACL鄰接程式設計，這強制進行此軟體處理並在每個流中對初始資料包使用NetFlow資源（而不是硬體ACL TCAM）。然後將封包封裝在GRE中並轉送到WCCP裝置。

NetFlow條目的建立會影響CPU利用率，但後續的資料包轉發是在硬體中完成的。流量模式（尤其是唯一流的數量）決定了CPU的利用率。如果消耗了Catalyst 6500的NetFlow資源，則會在軟體中轉發所有流量。

Supervisor PFC的NetFlow資源在不同平台上有所不同。目前，最大的NetFlow資源在Supervisor引擎720平台上的PFC-3BXL上可用。

L2轉發方法

使用L2轉發時，服務組中的WCCP實體（ACNS、WAFS、WAAS等）屬於同一子網，並且與Catalyst 6500相鄰的L2。這樣可以實現高吞吐量、低延遲的流量重定向。入口介面（配置WCCP的位置）和WCCP裝置所在的介面必須位於不同的VLAN上。

附註：使用L2重新導向時，封包會重新寫入，並將來源MAC設定為路由器，目的地MAC設定為快取引擎。此重新導向方法的唯一缺點是，快取引擎必須可由Catalyst 6500連線到L2，且必須位於與已設定的輸入WCCP介面不同的第3層介面上。

附註：轉發到WCCP裝置的方法可能與WCCP裝置用於將流量傳送回Catalyst 6500的方法不同。WCCP用於協商兩台裝置均支援的轉發和返回方法。請參閱WCCP返回方法。

在此案例中，可用於WCCP重新導向的選項包括：

• 輸入 — L2重新導向+雜湊分配；這需要軟體處理。
• 輸入 — L2重新導向+遮罩指派，這要求進行完整的硬體處理，因此建議使用。
• 輸出 — L2重定向+雜湊分配；這需要軟體處理。
• 輸出 — L2重新導向+遮罩指派；這需要軟體處理。

輸入 — L2 +雜湊分配

當在入口上配置第2層+雜湊分配時，WCCP流量將傳送每個流中的第一個資料包進行軟體交換，從而在硬體NetFlow表中建立NetFlow條目。

附註：NetFlow流量掩碼設定為介面全流量模式，這可能會影響交換機上配置的其他NetFlow功能。

由於WCCP是一種無狀態機制，因此不會在軟體中維護資訊；相反，它在硬體中維護為NetFlow表中的條目。只要NetFlow表條目存在，就會在硬體中轉發流中的後續流量。

NetFlow條目的建立會影響CPU利用率，但後續的資料包轉發是在硬體中完成的。流量模式（尤其是唯一流的數量）決定了CPU的利用率。如果消耗了Catalyst 6500的NetFlow資源，則會在軟體中轉發所有流量。

Supervisor PFC的NetFlow資源在不同平台上有所不同。目前，最大的NetFlow資源在Supervisor引擎720平台上的PFC-3BXL上可用。

輸入 — L2 +掩碼分配

在輸入上設定時，L2 +遮罩分配是Catalyst 6500支援的最有效WCCP方法。所有流量均進行硬體交換，包括每個流中的初始資料包。不需要軟體重新導向；初始和後續資料包轉發由硬體提供。

Catalyst 6500的硬體ACL TCAM資源用於在收到任何WCCP封包之前對硬體專案進行預程式設計。

為了使用此方法和利用完全硬體交換，WCCP實體還必須支援L2重定向和基於掩碼的分配方法。此方法的配置在WCCP實體上完成，Catalyst 6500在WCCP與WCCP實體/組的初始通訊期間會協商最佳方法。

輸出 — L2 +雜湊分配

通過出口L2 +雜湊分配，WCCP流量將每個流中的第一個資料包傳送到軟體交換，從而在硬體NetFlow表中建立NetFlow條目。

附註：NetFlow流量掩碼設定為介面全流量模式，這可能會影響交換機上配置的其他NetFlow功能。

此外，當在出口方向上配置時，需要對流的第一個資料包進行額外的轉發資訊庫(FIB)查詢，以確定與CE相關聯的鄰接關係，這要求Catalyst 6500內的資料包重新循環。後續資料包在硬體中進行NetFlow交換。

NetFlow條目的建立會影響CPU利用率，但後續的資料包轉發是在硬體中完成的。流量模式（尤其是唯一流的數量）決定了CPU的利用率。如果消耗了Catalyst 6500的NetFlow資源，則會在軟體中轉發所有流量。

Supervisor PFC的NetFlow資源在不同平台上有所不同。目前，最大的NetFlow資源在Supervisor引擎720平台上的PFC-3BXL上可用。

輸出 — L2 +掩碼分配

在出口方向配置時，L2 +掩碼分配會交換軟體中每個流中的第一個資料包，與L2 +雜湊分配的情況類似。後續資料包在硬體中進行NetFlow交換。

附註：NetFlow流量掩碼設定為介面全流量模式，這可能會影響交換機上配置的其他NetFlow功能。

PFC2和PFC3不支援輸出ACL鄰接程式設計，這強制軟體處理每個流中的初始資料包；在硬體中轉發流中的後續資料包。

NetFlow條目的建立會影響CPU利用率，但後續的資料包轉發是在硬體中完成的。流量模式（尤其是唯一流的數量）決定了CPU的利用率。如果消耗了Catalyst 6500的NetFlow資源，則會在軟體中轉發所有流量。

Supervisor PFC的NetFlow資源在不同平台上有所不同。目前，最大的NetFlow資源在Supervisor引擎720平台上的PFC-3BXL上可用。

WCCP返回方法

WCCP實體可以為請求提供服務

當WCCP用於攔截流量並且WCCP實體對這些資料包執行完整操作時，資料包就可以從WCCP裝置傳送回客戶端。此正常處理的流量（目的地為網路上的客戶端）在從WCCP裝置傳送回客戶端時不需要任何特殊封裝。

由於WCCP偵聽導致客戶端請求被成功服務（來自快取的檔案、來自快取的拆分流、來自WAAS的檔案），因此它可以作為正常流量傳送回網路，資料包中的目標地址是原始請求者。如果此流量在WCCP裝置到客戶端的網路路徑中，Catalyst 6500通常可以進行L3/交換；如果使用L2連線的WCCP裝置，則流量位於網路路徑中。無需進行封裝即可將其從WCCP裝置傳送回Catalyst 6500，因為目的地現在是原始使用者端，而不是網際網路或內聯網上的伺服器。然後，網路會像處理任何其他IP流量一樣處理此情況，並使用Catalyst 6500中的硬體轉送，以便將所請求的流量傳回使用者端。

WCCP實體無法為請求提供服務

在WCCP實體無法執行所請求操作的情況下，WCCP裝置可能需要將流量傳送回Catalyst 6500並保留資料包的原始目的地。在不進行封裝的情況下從WCCP實體轉發此流量可能會導致流量環路。為了從客戶端隱藏未成功的服務嘗試並將資料包傳送到要服務的原始目的地，資料包必須保持不變、放回其原始轉發路徑並在沒有WCCP偵聽的情況下轉發到原始目的地。

在WCCP返回方法中，WCCP可用於封裝這些資料包，將它們傳送回最初攔截它們的裝置，剝離任何封裝，並將它們放回被攔截的轉發路徑中。這些資料包需要正常傳送，就像它們從未被WCCP截獲一樣。

這些案例包括：

• 快取過載的流量，其中流量被繞過
• 拒絕WCCP實體服務流量的快取裝置規則
• 正在查詢裝置上不可用的服務的繞過流量

目前，此返回方法只能使用GRE封裝完成，而所有Catalyst 6500硬體均不支援此方法。如果使用此方法將大量流量傳送回Catalyst 6500，則可能會發生CPU使用率較高的情況，因為此流量是在軟體中進行處理的。在Cisco IOS軟體版本12.1(18)SXH中，Catalyst 6500硬體支援的是一種第2層返回方法。

GRE返回

在低於12.2(18)SXH的Cisco IOS軟體版本中，Catalyst 6500支援的唯一傳回方法是GRE封裝。除了附加到返回流量的GRE報頭之外，還會附加WCCP報頭。儘管Supervisor引擎32和Supervisor引擎720硬體本機支援GRE，但是此附加報頭導致GRE不是硬體輔助的。請注意，Catalyst 6500和WCCP裝置都必須支援和協商L2返回方法。

對於任何GRE、輸入、輸出或WCCP返回，Supervisor Engine 2中都不存在GRE硬體支援。為了處理此型別的GRE解除封裝，Cisco IOS軟體在啟用WCCP的介面上對WCCP GRE通道接收 — 鄰接進行程式設計，以指向路由處理器(RP)，這導致返回流量的軟體處理。

在Catalyst 6500上使用重新導向清單以避免可能需要透過GRE返回的流量，是減少將從WCCP實體回送的流量的軟體處理需求的有效方法。這比在WCCP實體上拒絕流量、強制流量進行GRE封裝並傳送回Catalyst 6500要有效得多。

請記住，WCCP服務組是可擴展的。如果由於負載而繞過過多的流量，則會傳送回此流量，這會在Catalyst 6500上造成CPU負載。正確擴展WCCP服務組甚至過度構建是避免這種情況發生的唯一方法。

L2傳回增強功能

在12.2(18)SXH中，一個選項允許WCCP實體重寫第2層MAC地址，而不是封裝返回流量。此L2返回增強功能(Cisco錯誤ID CSCuk59825)可在WCCP設定為使用輸入重新導向與遮罩指定時，對返回流量進行硬體處理。

WCCP選項摘要

在Catalyst 6500上實施時，WCCP提供許多配置選項，如下表所示。請注意，WCCP裝置會協商這些選項並控制Catalyst 6500使用哪些選項。配置在WCCP連線的WCCP裝置端完成。

從硬體角度看，所有出口WCCP配置都需要軟體處理並影響CPU利用率。當使用基於雜湊的分配方法時，入口還需要進行軟體處理，從而對CPU利用率產生相同的潛在影響。

建議在Catalyst 6500上部署WCCP的方法是使用遮罩分配的L2重新導向，並在可用時返回L2。

提示：只有一個選項可確保高效能、基於硬體的完全轉發：在Supervisor Engine 2、Supervisor Engine 32和Supervisor Engine 720上使用遮罩指派進行輸入型L2重新導向。

WCCP設計建議

使用這些配置建議，您可以確定適合您情況的最佳WCCP部署方法。

摘要

設計網路，以便使用WCCP入口作為重定向方法。一個好的設計方法是將快取交換塊作為分層的L3分佈網路的一部分；這可確保WCCP服務的流量可以在幾個主要入口埠上識別。

• 使用12.2(18)SXF7或更新版本的Cisco IOS軟體。
• 識別並重定向入口介面上的流量。
• 使用支援L2重定向方法的WCCP裝置。
• 使用支援基於掩碼的分配方法的WCCP裝置。
• 如有可能，在Catalyst 6500上為無法由WCCP裝置服務的流量使用重新導向清單。
• 使用Supervisor Engine 720調整帶有出口或任何基於雜湊的分配配置的NetFlow計時器。
• WCCP裝置應具有專用的L3環境和SVI/VLAN介面。

此外，思科高級服務還推薦以下設計注意事項：

• 在無法通過掩碼分配進行完全L2重定向的環境中，Supervisor Engine 720的表現並不比Supervisor Engine 2平台更好。在這種情況下不要升級硬體並期待獲得更好的效能。
• 對於具有高流量需求的大型中心站點部署，請考慮使用基於策略的路由(PBR)和思科內容交換模型(CSM)/應用控制引擎(ACE)進行設計，以便攔截和轉發流量。
• WCCPv2在完美的情況下如預期般發揮作用。但是，在某些情況下，路由器上的CPU使用率可能會達到較高水準，從而導致裝置不可用且需要重新載入：
  
  
  • WCCPv2從入口硬體加速的L2掩碼分配模式回退到需要MSFC上CPU的任何其他模式。
  • WCCP配置錯誤（例如，輸出而非輸入或L2雜湊而非掩碼分配）。
• 使用Catalyst 6500的任何高容量WCCP部署（快取、流、WAAS或其他「高通訊速率」方案）應在完全生產部署之前對即時通訊進行效能測試。

其他建議

在交換器上使用重新導向清單，以避免將封包傳送回Catalyst 6500。如果可以將快取裝置的任何規則作為重定向清單移動到Catalyst 6500，這可能會提供更好的硬體效能。

如果您使用除輸入 — L2遮罩分配以外的任何方法，Supervisor Engine 720平台上的NetFlow資源可能會很快耗盡。Supervisor Engine 720提供的效能並不比Supervisor Engine 2的任何其他方法更好。

如果非最佳設計必須使用Supervisor引擎720或Supervisor引擎32，請考慮使用mls ip netflow creation software-mode fast命令，以便加快WCCP初始資料包的NetFlow處理。這將刪除新增到Supervisor Engine 32和Supervisor Engine 720 NetFlow的增強功能，並提供與Supervisor Engine 2 NetFlow硬體相同的效能。

用於掩碼分配的思科內容引擎(CE)的配置為：

• wccp第2版
• wccp路由器清單 number ip-address
• wccp 服務 router-list-num num mask-assign

使用以下命令檢視NetFlow利用率並確定WCCP是否正在使用NetFlow條目並且正在使用軟體處理：

• show mls netflow table-contention detailed
• show mls netflow ip sw-installed
• show mls netflow aging
• show mls netflow ip dynamic count
• show mls netflow ip count
• show mls ip
• show fm netflow counters

如果您因為正在使用NetFlow資源而遇到WCCP軟體問題，這些命令可能會積極地清除現有條目並為新條目創造空間。（如果條目數僅比NetFlow空間多一點，則此操作將無效。）

• mls老化快速時間3 threshold 1
• mls老化長64
• mls老化正常32
• mls ip netflow creation software-mode fast（這會禁用某些不在Supervisor Engine 2中的Supervisor Engine 720 NetFlow更改。）

為避免丟包，WCCP實體必須將流量重定向出不是配置WCCP的介面的介面。在這種情況下，如果符合所有條件，Catalyst 6500 WCCP會捨棄封包：

• 客戶端和WCCP實體位於同一個L3介面上。
• 在此介面上應用WCCP重定向策略。
• 使用GRE重新導向方法。
• 需要重定向資料包分段。
• 使用管理引擎720。

此情況是由內建於Catalyst 6500中的保護機製造成的；cisco IOS軟體已進行檢查，防止封包進入和離開相同的Cisco IOS軟體虛擬介面，在那裡它可能會產生回圈和導致不想要的行為。將WCCP裝置移至其專用的第3層環境，以防止發生這種情況。

基於使用者的速率限制(UBRL)和WCCP不會在介面上同時工作，因為存在流量掩碼。每個單播功能的每個介面都有一個流掩碼。WCCP要求全流，UBRL使用src-only或dst-only。

12.2(18)SXF5中為Supervisor Engine 2和L2返回新增了WCCP支援。在2007年4月/5月的12.2(18)SXH之前，Supervisor Engine 720不提供此支援。

Cisco IOS軟體伺服器負載平衡(SLB)僅支援WCCP L2 PFC重新導向；其他WCCP配置不相容，而GRE無法正常工作。WCCP accelerated命令僅適用於Supervisor Engine 2/MSFC2。其目的是強制路由器協商掩碼分配和L2重定向，這意味著所有WCCP重定向在硬體中完成。Supervisor Engine 32和Supervisor Engine 720無需此命令即可協商此情況。

解決方案

附註：使用命令查詢工具(僅供已註冊客戶使用)可獲取本節中使用的命令的更多資訊。

ACNS

對於標準透明快取重定向，請記住，WCCP實體為WCCP路由器提供支援的方法，並且可能需要進行相應配置。對於Cisco ACNS，此示例配置請求最佳化的L2重定向和基於掩碼的分配方法：

1. 確保您擁有適用於Catalyst 6500最佳化的WCCPv2:
   
   

   ContentEngine(config)# wccp version 2

2. 設定定義要使用的Catalyst 6500的路由器清單：
   
   

   ContentEngine(config)# wccp router-list 1 172.16.16.1

3. 配置服務以使用最佳化方法：
   
   

   ContentEngine(config)# wccp service router-list-num 1 l2-redirect mask assign

在路由器端，Catalyst 6500設計應確保WCCP裝置位於不在當前流量路徑（入口或出口）中的專用L3介面上。 為了提升硬體效能，應該擷取傳入Catalyst 6500的流量，即使這要求設定更多的介面，而不是選擇單一輸出介面。理想的設計是在到達此裝置之前聚合所有流量，並且只有幾個介面需要WCCP入口配置。

Catalyst 6500上的WCCP配置應該是：

1. 配置WCCPv2:
   
   

   6500Switch# ip wccp version {1 | 2}

2. 配置WCCP服務組。
   
   

   6500Switch (config)# ip wccp service [accelerated] redirect-list access-list

   僅對帶有12.1E Cisco IOS軟體的Supervisor Engine 2平台使用accelerated命令。

重新導向清單用於識別應選擇或不選擇進行重新導向的流量。回想一下，此ACL可以在硬體中執行，這是防止無法由WCCP裝置服務的流量進行重定向的更有效方式。傳送到裝置但無法在此提供服務的流量必須返回到此Catalyst 6500才能放回原始流量路徑，這需要進行額外處理。WCCP訪問清單是標準訪問清單或擴展訪問清單。

此範例顯示，從10.1.1.1到12.1.1.1的所有要求都會繞過快取，而所有其他要求都會重新導向。

6500Switch(config)# ip wccp service redirect-list 120
6500Switch(config)# access-list 120 deny tcp host 10.1.1.1 any
6500Switch(config)# access-list 120 deny tcp any host 12.1.1.1
6500Switch(config)# access-list 120 permit ip any any

在接收要重定向的流量的每個入口介面上配置入口WCCP方法：

Router(config-if)# ip wccp service redirect in

這將完成WCCP裝置和交換機上的配置，因此此時應該進行流量重定向。

裝置的最終WCCP配置如下所示。

wccp version 2
wccp router-list 1 router-ip-addresses
wccp service router-list-num 1 l2-redirect mask assign

ip wccp version 2
ip wccp service redirect-list 120
access-list 120 deny tcp ...
access-list 120 deny udp ...
access-list 120 permit ip any any

ip wccp redirect service in

要檢查此配置，請輸入以下命令：

Show ip wccp service detail

有關其他WCCP配置選項（例如使用組播的組定址或其他WCCP安全性），請參閱使用WCCP配置Web快取服務。

WCCP IOS Show和Debug命令

• show ip wccp service-number — 提供「Total Packets Redirected」計數。此計數是重定向的流或會話數。
• show ip wccp service-number detail — 提供「Packets Redirected」計數。計數是重定向的流或會話數。
• show ip wccp web-cache detail — 用於指示有多少資料流而不是資料包正在使用第2層重定向。
• clear ip wccp — 重置「Packets Redirected」資訊的計數器。
• show ip wccp service-number view — 顯示屬於服務組的WCCP裝置。
• show ip wccp service-number service — 顯示服務的雜湊、埠和WCCP優先順序。當在介面上配置了多個服務時，首先會命中優先順序較高的服務。
• debug ip wccp events — 診斷WCCP協定的狀態。
• debug ip wccp packets — 檢查WCCP資料包處理實體之間的通訊。

使用WCCP和硬體轉發時，某些計數器可能不會按預期顯示：

• 如果WCCP ACL完全在硬體中處理，WCCP計數器可能無法顯示準確的資料包計數。
• 如果WCCP使用基於雜湊的分配和NetFlow硬體資源，則WCCP計數器可能反映流的數量而不是資料包的數量。

NetFlow命令

如果您的WCCP配置要求使用NetFlow硬體資源，請使用以下多層交換(MLS)和Fabric Manager(FM)命令，以便檢視NetFlow資源的狀態：

• show mls netflow table-contention detailed
• show mls netflow ip sw-installed
• show mls netflow aging
• show mls netflow ip dynamic count
• show mls netflow ip count
• show mls ip
• show fm netflow counters

WCCP缺陷

此思科錯誤ID和解決方法的表支援使用Cisco IOS軟體版本12.2(18)SXF7或更高版本以獲得WCCP最佳支援的一般建議。