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

简介

本文描述如何使用在Cisco Catalyst 6500系列平台的WEB缓存通信协议(WCCP)。

WCCP最初设计，当方法拦截Web流量(HTTP)和转发它到本地缓存设备，可能服务对从一个本地位置的一个客户端和保存昂贵WAN带宽。

从网络用户方面， WCCP透明，因为用于在网络级，不用任何特别配置由用户，为了识别和重定向横断第3层的Web流量(L3)设备到本地缓存设备。虽然WCCP为Web流量最初设计，重定向透明方法变为一非常有用的机制涉及其他问题以在低音量链路的大容积内容。为此，其它协议支持被添加了到最新WCCP版本。这些另外的技术包括协议例如HTTP、HTTPS、FTP、视频流和文件缓存技术，例如通用网络文件系统(CIFS)。这些技术支持更新的Cisco解决方案和平台，例如广域文件服务(WAFS)、广域应用服务(WAAS)，面向应用的应用和内容网络软件(ACNS)的网络(AON)和高级功能。

WCCP采用增加，当企业实现最新的生产率工具例如基于视频的通信和培训，以及居住和根据要求视频。努力控制开销，例如整理过的数据数据中心，创建需要对于WCCP支持其他，非常高带宽服务。

由于WCCP的重要性与今天内容富有的网络的，一些平台，例如Catalyst 6500，实现与WCCP的硬件辅助的性能，以便减少为协议要求的CPU负载。本文描述如何部署在Catalyst 6500的WCCP为了最大化硬件利用率和减少CPU负载。

先决条件

要求

Cisco 建议您了解以下主题：

• WCCP
• Cisco Catalyst 6500系列交换机
• Cisco IOS®软件

使用的组件

本文档中的信息基于以下软件和硬件版本：

• Cisco Catalyst 6500 系列交换机
• Cisco IOS软件版本12.1(50)SY或以上用Supervisor引擎2T (Policy Feature Card 4)
• Cisco IOS软件版本12.2(18)SXD1或以上用Supervisor引擎720 (Policy Feature Card 3)

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您使用的是真实网络，请确保您已经了解所有命令的潜在影响。

WCCP功能概述

一般被称为的功能WCCP实际上介入三个组件：

1. 功能仅实现在路由器或交换机
2. 功能仅实现在处理实体，例如Web缓存
3. 在两边实现的WCCP

本文检查这三种WCCP运行特性：

1. 分配方法确定哪个WCCP流量，并且哪个WCCP设备为流量的目的地选择。一起集群的WCCP协议支持多个设备。
2. 重定向方法寄通信流给WCCP设备，当有需要从流量横贯的正常的网络路径时更改。
3. 回归方法确定流量如何被退还的到从WCCP设备的路由器，如果流量不可能被服务。在WCCP设备服务请求处，数据包返回直接地给申请人。

WCCP和Catalyst 6500

Catalyst 6500 Supervisor引擎2、Supervisor引擎32和Supervisor引擎720支持这些WCCP功能和方法：

• WCCP版本2 (WCCPv2)
• 基于HASH的分配方法
• 基于掩码的分配方法(硬件加速的)
• L3通用路由封装(GRE)重定向方法(硬件加速的在Supervisor引擎32和Supervisor引擎720)
• Layer2 (L2)重定向方法(硬件加速的在Supervisor引擎2、Supervisor引擎32和Supervisor引擎720)
• GRE返回方法
• L2返回方法用Cisco IOS软件版本12.2SXH (硬件加速的在Supervisor引擎2、Supervisor引擎32和Supervisor引擎720)

欲了解更详细的信息在这些功能，参考配置在Cisco 6500系列Cisco IOS软件配置指南的WCCP， 12.2SX。

WCCP分配方法

WCCP分配确定哪个流量WCCP协议重定向，并且哪个WCCP实体收到重定向的数据流。

当WCCP配置在路由器的接口和在WCCP实体时，重定向的设备(Catalyst 6500)需要了解什么流量将重定向，并且流量将发送的地方。WCCP实体在服务组内集群全部通过WCCP协议通信用Catalyst 6500;然而，一个WCCP设备选择代表集群为了控制集群如何运行(用分配方法，重定向方法，等等)。WCCP设备和路由器可能协商数据包在服务组中被分配在Web缓存之间的方法。服务组定义作为32路由器和32个WCCP实体之间的一越来越多的关系。协商是由服务组;因此，参加几服务组的Web缓存可能协商每服务组的一个不同的分配方法。现在可以得到的WCCP服务是：

*用户可配置的服务在有一interface level命令已应用的Catalyst 6500实现对入站和出站方向。选择的暗示入站或出站讨论以后，但是入站首选方法，因为重定向列表可以加上最大硬件性能的WCCP。

一旦配置为WCCP，路由器通告一服务组的支持的分配方法WCCP通信消息的。缺乏这样消息暗示Catalyst 6500支持仅默认基于HASH的分配方法。

一旦在Catalyst 6500和WCCP设备之间的协商完成， WCCP选定的实体，通过WCCP，通知Catalyst 6500什么流量将重定向，并且对哪些WCCP实体流量分配。为例，当有超过可用时，四个WCCP的设备WCCP实体在服务组中可能通知Catalyst 6500重定向从特定子网的所有Web流量缓存引擎1 - 4。

有两个分配方法可用为WCCP ：

1. 基于HASH的分配(默认)与从WCCP指定设备的方针一起使用一基于软件的散列算法为了确定哪个WCCP设备收到流量。在Supervisor引擎32或Supervisor引擎720平台中， Netflow硬件资源用于为了运用某个级别硬件协助。
2. 基于掩码的分配使用Catalyst 6500的硬件功能，特别地访问控制表(ACL)三重内容可编址存储器，为了分配流量到WCCP实体。这是首选方法。

所有设备在WCCP服务组内必须使用同一个分配方法。在WCCP实体配置并且Catalyst 6500了解分配方法。参考的WCCP设计建议欲了解更详细的信息。

基于HASH的分配方法详细信息

基于HASH的分配机制依靠在软件方面执行的算法。为了有效利用散列算法，在特定的流量的第一数据包从硬件路径发送到哈希执行的软件路径。

软件执行流的多种组件一XOR哈希拆分对多种WCCP实体的通信流并且出来与哈希。哈希机制确定流量如何在联机WCCP实体中被分配。

哈希结果被编程到在该流的后续信息包转发的硬件Netflow表。不管字段可用为切细由WCCP，使用全双工五元组。这意味着Netflow被放到接口，全流模式，当WCCP启用时。这有在可能要求Netflow资源的其它特性的暗示。欲了解更详细的信息请参阅WCCP缺陷部分。

关于WCCP的一个常见问题在Catalyst 6500是， “为什么执行CPU利用率增加，当我启用WCCP时？”当基于HASH的分配是在使用中的时，基于软件的处理在每个流的初始数据包给CPU添负担并且经常是增加的利用率的原因。使用现在可以得到的Policy Feature Card 3 (PFC3)转发硬件，如果WCCP配置作为出口功能或，如果基于HASH的分配是在使用中的(入口或出口)，某个级别软件处理总是要求。

使用基于HASH的分配方法影响这些功能：

• Netflow表- PFC支持的条目数量被限制和流掩码更改建立接口全流整个Netflow表的。
• CPU利用率-，因为在每个流的第一数据包是交换的软件有在CPU利用率的一增加。
• 性能-流量发送对查找的CPU的速率被限制，以便CPU保护。
• Netflow功能-使用Netflow资源的其它特性也许被影响，如果Netflow资源由WCCP浪费。

软件处理的基于HASH的分配需求造成的限制和暗示是可适用的对入口和出口流量。在CPU的影响可以被恶化，如果网络经过非典型流量模式，例如服务拒绝(DoS)攻击。在典型的攻击或蠕虫病毒爆发，主机发送的每数据包是到新建目标或端口，在软件方面造成每数据包处理。因为WCCP重定向的数据流明确地发送对处理的最初数据包的CPU，有保护被限制的方法。使用‘拒绝’在接口的ACL条目能限制什么发送对CPU;然而，没有速率防幅器或其他保护攻击的这些类型。

基于掩码的分配方法详细信息

基于掩码的分配取决被处理的不同地是否配置在入口或在出口。

使用入口基于掩码的分配，掩码被编程到在信息包转发前的ACL TCAM，因此Netflow表和软件处理不是需要的。WCCP实体选择一定数量的HASH桶并且分配地址掩码和WCCP设备到每个桶。一旦分配完成， Supervisor编程一个TCAM条目和一硬件邻接每个桶的并且重定向匹配地址掩码到相关的WCCP设备通过L2重写的数据包。

如果WCCP配置作为入口功能，在硬件ACL表里可能使用ACL重定向邻接条目。一旦WCCP匹配条目，使用一适当的邻接为了执行任一L2重写或GRE封装。因此，当掩码分配在入口时使用，两个L2重写(Supervisor引擎2、Supervisor引擎32和Supervisor引擎720)和GRE封装(Supervisor引擎32和Supervisor引擎720仅)在硬件方面被执行。

如果WCCP配置作为出口功能，硬件方面不支持ACL重定向邻接，因为在流的数据包由系统已经路由。流的第一数据包发送对处理的软件。一旦确定适当的重定向邻接，被编程到Netflow硬件(而不是ACL TCAM)，其中对执行任一L2重写或GRE封装的邻接的进入点。在流的后续信息包在硬件方面重定向由Netflow硬件。

注意：如果WCCP配置作为出口功能，掩码分配要求处理的软件，否定基于掩码的分配方法的所有好处。

两个基于掩码的选项，仅入口掩码根据初始和后续信息包的分配enable (event)全双工基于硬件的转发。所有其它选项，例如处理使用基于HASH的分配或的出口，导致后续信息包初始数据包和硬件Netflow交换的转发的软件交换。

WCCP重定向方法

WCCP实体，不是Catalyst 6500，指明散列表，并且掩码/值设置为Catalyst 6500，因此重定向方法的配置被执行在该设备和不在Catalyst 6500交换机。Catalyst 6500根据与WCCP实体/组的WCCP通信确定最好的重定向方法联机。此协商确定重定向的数据流如何转发到设备。有两个重定向选项：L3 (GRE)和L2 (MAC地址重写)。

使用WCCPv1，唯一选择是L3重定向，亦称GRE封装。使用L3重定向，每WCCP重定向的数据包在GRE报头被封装标记用四八位字节WCCP重定向报头0x883E跟随的协议类型，随后发送到WCCP设备(例如Cache Engine)。

使用WCCPv2的介绍， L2重定向，亦称加速WCCP重定向，被添加为了利用硬件交换平台例如Catalyst 6500。当WCCP使用L2重定向时， WCCP设备和Catalyst 6500必须是相邻的L2 (在同样L2 VLAN)内。重定向的L2流量不使用GRE封装;反而， MAC目的地址由Catalyst 6500重写对那L2-connected WCCP实体并且通过正常硬件交换转发。

注意：转发方法对WCCP设备的可能不是WCCP设备使用为了送回流量到Catalyst 6500的同一个方法。WCCP用于为了协商两设备支持的转发和回归方法。请参阅WCCP返回方法。

L3 (GRE)转发方法

WCCP L3操作介入使用GRE作为封装方法。重定向的数据包在与0x883e协议类型的一个GRE报头被封装，与包括匹配的服务ID和哈希桶的4字节WCCP重定向报头一起(仅WCCPv2)。使用GRE启用从Catalyst 6500将分离的WCCP客户端由多L3 (路由)跳。

在此方案中，选项可用为WCCP重定向包括：

1. 入口- L3 (GRE)重定向+哈希分配;这要求软件处理。
2. 入口- L3 (GRE)重定向+掩码分配;这要求处理全双工的硬件并且是仅可用的在Supervisor引擎32或Supervisor引擎720。
3. 出口- L3 (GRE)重定向+哈希分配;这要求软件处理。
4. 出口- L3 (GRE)重定向+掩码分配;这要求软件处理。

入口- L3 (GRE)重定向+哈希分配

在Supervisor引擎2上，每GRE数据包发送对处理的多层交换机特性卡(MSFC)。因为硬件方面不支持GRE封装， MSFC必须应用GRE和WCCP报头，强制所有流量的软件交换。

使用基于HASH的分配方法， Supervisor引擎32和Supervisor引擎720转发第一数据包每个流在软件方面，以便Netflow条目设立。数据包在GRE然后被封装(封装，并且初始数据包的转发在软件方面完成)并且转发到WCCP设备。

Netflow条目的建立影响CPU利用率，但是后续信息包转发在Supervisor引擎720和Supervisor引擎的32硬件方面完成。流量模式，唯一流特别是数量，指明多少使用CPU。如果Catalyst 6500的Netflow资源浪费，则所有流量在软件方面转发。

Supervisor PFC的Netflow资源在多种平台间有所不同。目前，最大的Netflow资源是可用的在Supervisor引擎720平台的PFC-3BXL。

入口- L3 (GRE)重定向+掩码分配

在Supervisor引擎2上，每GRE数据包发送对处理的MSFC。因为硬件方面不支持GRE封装， MSFC必须应用GRE和WCCP报头，强制所有流量的软件交换。

使用基于掩码的分配方法， Supervisor引擎32和Supervisor引擎720转发初始和后续信息包在硬件方面，因为本地支持GRE和掩码分配使用ACL TCAM硬件转发。

出口- L3 (GRE)重定向+哈希分配

在Supervisor引擎2上，每数据包发送对处理的MSFC。因为硬件方面不支持GRE封装， MSFC必须应用GRE和WCCP报头，强制所有流量的软件交换。

使用基于HASH的分配方法用Supervisor引擎32和Supervisor引擎720， Catalyst 6500在软件方面转发初始数据包每个流，以便Netflow条目设立。数据包在GRE然后被封装并且转发对WCCP实体。

Netflow条目的建立影响CPU利用率，但是后续信息包转发在硬件方面完成。流量模式，唯一流特别是数量，指明多少使用CPU。如果Catalyst 6500的Netflow资源浪费，则所有流量在软件方面转发。

Supervisor PFC的Netflow资源在多种平台间有所不同。目前，最大的Netflow资源是可用的在Supervisor引擎720平台的PFC-3BXL。

出口- L3 (GRE)重定向+掩码分配

在Supervisor引擎2上，每数据包发送对处理的MSFC。因为硬件方面不支持GRE封装， MSFC必须应用GRE和WCCP报头，强制所有流量的软件交换。

使用基于掩码的分配方法用Supervisor引擎32和Supervisor引擎720，第一数据包每个流是交换的软件，以便Netflow条目设立。Supervisor都不支持出口编程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，等等)在服务组内是相同子网的一部分并且是L2在Catalyst 6500附近。这启用高吞吐量，流量的低延时重定向。入口接口(其中WCCP配置)和WCCP设备查找的接口必须在不同的VLAN。

注意：使用L2重定向，数据包以源MAC重写设置为路由器和目的地MAC设置为Cache Engine。此重定向方法唯一的缺点是Cache Engine在一个不同的L3接口比已配置的入口WCCP接口必须是L2可及的由Catalyst 6500，并且必须驻留。

注意：转发方法对WCCP设备的可能不是WCCP设备使用为了送回流量到Catalyst 6500的同一个方法。WCCP用于为了协商两设备支持的转发和回归方法。请参阅WCCP返回方法。

选项可用为WCCP重定向在此方案包括：

• 入口- L2重定向+哈希分配;这要求软件处理。
• 入口- L2重定向+掩码分配这要求处理全双工的硬件和推荐。
• 出口- L2重定向+哈希分配;这要求软件处理。
• 出口- L2重定向+掩码分配;这要求软件处理。

入口- L2 +哈希分配

当配置在入口与L2 +哈希分配， 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方法。所有流量是硬件交换，包括在每个流的初始数据包。软件重定向没有要求;硬件提供初始和后续信息包转发。

在所有WCCP数据包接收前， Catalyst 6500的硬件ACL TCAM资源用于为了预编程序硬件条目。

为了使用此方法和使用全双工硬件交换， WCCP实体必须也支持L2重定向和基于掩码的分配方法。此方法的配置在WCCP实体完成，在与WCCP实体/组的WCCP初始通信期间，并且Catalyst 6500协商佳方法。

出口- 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设备的网络路径给客户端，此流量可以通常是L3/switched由Catalyst 6500;使用L2附加的WCCP设备，流量在网络路径。因为目的地当前是原始客户端而不是在互联网或内联网的一个服务器封装不是需要的为了发送它回到从WCCP设备到Catalyst 6500。网络在Catalyst 6500然后处理此类似所有其他IP数据流并且使用硬件转发为了返回请求的流量对客户端。

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硬件支持的L2返回方法。

GRE返回

在Cisco IOS软件版本中早于12.2(18)SXH，为Catalyst 6500支持的唯一的回归方法是GRE封装。除GRE报头之外被添附对回程数据流， WCCP报头也被添附。虽然Supervisor引擎32和Supervisor引擎720硬件里本地支持GRE，此另外的报头导致的GRE硬件辅助。注意Catalyst 6500和WCCP设备必须支持和协商L2返回方法。

GRE硬件支持在任何GRE、入口、出口或者WCCP返回的Supervisor引擎2不存在。为了处理解封装此种的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实体重写L2 MAC地址而不是封装回程数据流。此L2返回增强(Cisco Bug ID CSCuk59825)启用硬件处理返回的流量，当WCCP配置以掩码分配时使用入口重定向。

WCCP选项摘要

如此表所显示，当实现在Catalyst 6500， WCCP提供许多配置选项。注意WCCP设备协商Catalyst 6500使用选项的这些选项和控制。配置在WCCP连接的WCCP设备侧被执行。

从硬件方面，所有出口WCCP配置要求处理的软件并且影响CPU利用率。当使用基于HASH的分配方法并且导致在CPU利用率时的同一潜在影响软件处理在入口也要求。

WCCP部署推荐的方法在Catalyst 6500的是L2与掩码分配，当联机， L2返回的重定向。

提示：仅一个选项保证高性能，全双工基于硬件的转发：与掩码分配的基于入口的L2重定向在Supervisor引擎2、Supervisor引擎32和Supervisor引擎720。

WCCP设计建议

请使用这些配置推荐，因此您能确定WCCP部署佳方法您的情况的。

摘要

设计网络这样WCCP入口可以使用作为重定向方法。遵循好的设计方法将有高速缓冲存储switchblock作为分层的一部分， L3分布式网络;这保证WCCP服务流量可以在一些主要入站端口识别。

• 请使用12.2(18)SXF7或更新的Cisco IOS软件。
• 识别并且重定向在入口接口的流量。
• 请使用支持L2重定向方法的WCCP设备。
• 请使用支持基于掩码的分配方法的WCCP设备。
• 若可能，请使用重定向列表在Catalyst 6500不可能由WCCP设备服务的流量。
• 调整有出口或所有基于HASH的分配配置的Netflow计时器用Supervisor引擎720。
• WCCP设备应该有一个专用的L3环境和SVI/VLAN接口。

另外，思科高级服务推荐这些设计注意事项：

• 在不充分地是L2与掩码分配的重定向的环境， Supervisor引擎720比Supervisor引擎2平台不执行好。在这种情况下请勿升级硬件并且期待更加好的性能。
• 对于大，与大容积流量要求的中心站点部署，考虑与基于策略的路由(PBR)的一设计，并且Cisco Content Switching模拟(CSM) /Application控制引擎(ACE)流量拦截和转发的。
• WCCPv2在完善的情况下作用正如所料。然而，在下一些情况，在路由器的CPU利用率能到达使设备不能使用，并且要求重新加载的高水平：
  
  
  • WCCPv2后退从入口硬件加速的L2基于掩码的分配模式到要求在MSFC的CPU的其他模式。
  • WCCP不正确地配置(例如，而不是入口的而不是掩码分配的出口或L2哈希)。
• 所有大容积WCCP部署用Catalyst 6500 (高速缓冲存储、流、WAAS，或者其他‘高数据流速率’方案)应该是用真实数据流测试的性能在全双工生产部署前。

其它建议

请使用重定向列表在交换机为了避免被退还的到Catalyst 6500的数据包。如果缓存设备的任何规则可以移动向Catalyst 6500，当重定向列表，这可能提供更加好的硬件性能。

除ingress-L2掩码分配之外，如果使用任何方法在Supervisor引擎720平台的Netflow资源可以迅速被耗尽。Supervisor引擎720比Supervisor引擎2不提供更加好的性能其他方法。

在Supervisor引擎720或Supervisor引擎32必须用于一非最优设计处，请考虑使用mls ip Netflow创建软件模式快速命令，以便Netflow处理WCCP初始数据包可以被加速。这删除增强被添加到Supervisor引擎32和Supervisor引擎720 Netflow并且提供性能相等与那Supervisor引擎2 Netflow硬件。

Cisco内容引擎的(CE)配置掩码分配的是：

• WCCP版本2
• WCCP路由器列表编号IP地址
• router-list-num数字WCCP的服务掩码分配

请使用这些命令为了查看Netflow利用率和确定WCCP是否用完Netflow条目和使用软件处理：

• 被选派的show mls netflow塔布莱争用
• sw安装的show mls netflow ip
• show mls netflow过期
• show mls netflow ip dynamic计数
• show mls netflow ip计数
• show mls ip
• 显示fm Netflow计数器

如果遇到WCCP软件问题，因为Netflow资源浪费，这些命令积极地可能清楚现有项和创建新的条目的空间。(这不帮助，如果有完全更多条目比有Netflow空间。)

• 老化短时间3阈值1的MLS
• 老化长64的MLS
• 老化正常32的MLS
• mls ip Netflow快速创建的软件模式(这禁用不在Supervisor引擎2.)的一些Supervisor引擎720 Netflow更改

要避免丢包， WCCP实体必须重定向流量在不是接口的接口外面WCCP配置。在这种情况下，当所有情况符合时， Catalyst 6500 WCCP丢弃数据包：

• 客户端和WCCP实体是在同一个L3接口。
• WCCP重定向策略在此接口应用。
• GRE使用重定向方法。
• 重定向信息包分段要求。
• 使用Supervisor引擎720。

此情况是由安装的保护机制造成的Catalyst 6500;Cisco IOS软件有防止数据包输入和留下同一个Cisco IOS软件虚拟接口可能潜在循环和引起负面的情况的检查。移动WCCP设备向他们自己专用的L3环境为了防止此。

基于用户的速率限制(UBRL)和WCCP在接口不同时运作由于流掩码。有每个接口的一个流掩码每个单播功能的。WCCP要求全流，并且UBRL使用src或dst。

WCCP支持为Supervisor引擎2和L2返回被添加了在12.2(18)SXF5。这不在直到12.2(18)SXH的Supervisor引擎720在April/2007年5月。

WCCP L2仅PFC重定向支持与Cisco IOS软件服务器负载均衡(SLB);其他WCCP配置不兼容，并且GRE不工作。WCCP加速的命令只适用于Supervisor引擎2/MSFC2。其目的将强制路由器协商掩码分配和L2重定向，因此意味着所有WCCP重定向在硬件方面完成。Supervisor引擎32和Supervisor引擎720协商此，不用对此命令的需要。

解决方案

注意：使用命令查找工具（仅限注册用户）可获取有关本部分所使用命令的详细信息。

ACNS

对于标准的透明缓存重定向，请收回WCCP实体提供WCCP路由器支持的方法，并且可能需要配置如此执行。对于Cisco ACNS，此配置示例请求优化L2-redirect和基于掩码的分配方法：

1. 保证您有Catalyst 6500优化的WCCPv2 ：
   
   

   ContentEngine(config)# wccp version 2

2. 配置定义了Catalyst 6500s使用的路由器列表：
   
   

   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

   仅请使用加速的命令Supervisor引擎2平台与12.1E Cisco IOS软件。

重定向列表用于为了识别应该为重定向选择或不选择的流量。收回此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安全，参考配置Web缓存服务使用WCCP。

WCCP IOS显示和调试指令

• show ip wccp服务编号-提供‘信息包总数重定向的’计数。此计数是流或者会话数量，重定向。
• show ip wccp服务编号详细信息-提供‘数据包重定向的’计数。计数是流或者会话数量，重定向。
• show ip wccp web-cache detail -提供多少个流的征兆，而不是数据包，使用L2重定向。
• clear ip wccp -重置计数器对于‘数据包重定向的’信息。
• show ip wccp服务编号视图-显示是服务组的一部分的WCCP设备。
• show ip wccp服务编号服务-显示服务的哈希、端口和WCCP优先级。当多个服务在接口时，配置更加高优先级的服务首先点击。
• debug ip wccp events -排除故障WCCP协议的状态。
• debug ip wccp packets -查看WCCP数据包处理实体之间的通信。

当您使用WCCP和硬件转发时，一些计数器可能不显示正如所料：

• 如果WCCP ACL在硬件方面处理完全， WCCP计数器可能不显示准确数据包计数。
• 如果WCCP使用基于HASH的分配和Netflow硬件资源， WCCP计数器可能反射流数量而不是数据包数量的。

Netflow命令

当您有要求使用Netflow硬件资源的WCCP配置时，请使用这些多层交换和组织管理器(FM)命令，因此您能查看Netflow资源的状况：

• 被选派的show mls netflow塔布莱争用
• sw安装的show mls netflow ip
• show mls netflow过期
• show mls netflow ip dynamic计数
• show mls netflow ip计数
• show mls ip
• 显示fm Netflow计数器

WCCP缺陷

Cisco Bug ID和解决方法此表支持一般建议使用Cisco IOS软件版本12.2(18)SXF7或以上为WCCP最好的支持。