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

简介

本文档介绍如何在Cisco Catalyst 6500系列平台上使用Web缓存通信协议(WCCP)。

WCCP最初设计为一种拦截网络流量(HTTP)并将其转发到本地缓存设备的方法，在本地缓存设备中，WCCP可以从本地位置提供给客户端并节省昂贵的广域网带宽。

从网络用户的角度来看，WCCP是透明的，因为它在网络级别使用，而用户无需进行任何特殊配置，以识别并重定向通过第3层(L3)设备的Web流量到本地缓存设备。虽然WCCP最初是为网络流量设计的，但是重定向的透明方法已经成为一种非常有用的机制，可以解决通过低容量链路处理高容量内容的其他问题。因此，在更高的WCCP版本中添加了其他协议支持。这些附加技术包括HTTP、HTTPS、FTP、视频流和文件缓存技术(如通用互联网文件系统(CIFS))等协议。 这些技术支持较新的思科解决方案和平台，如广域文件服务(WAFS)、广域应用服务(WAAS)、面向应用的网络(AON)，以及应用和内容网络软件(ACNS)的增强功能。

随着企业实施最新的生产力工具（如基于视频的通信和培训，以及实时视频和点播视频），WCCP的采用率也在增加。控制成本（如整合的数据中心）的努力使WCCP需要支持额外的极高带宽服务。

由于WCCP对当今内容丰富网络的重要性，某些平台（如Catalyst 6500）已通过WCCP实现硬件辅助性能，从而降低协议所需的CPU负载。本文档介绍如何在Catalyst 6500上部署WCCP，以最大限度地提高硬件利用率并减少CPU负载。

先决条件

要求

Cisco 建议您了解以下主题：

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

使用的组件

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

• Cisco Catalyst 6500 系列交换机
• 带管理引擎2T（策略功能卡4）的思科IOS软件版本12.1(50)SY或更高版本
• 带管理引擎720（策略功能卡3）的思科IOS软件版本12.2(18)SXD1或更高版本

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

WCCP功能概述

通常称为WCCP的功能实际上包含三个组件：

1. 仅在路由器或交换机上实现的功能
2. 仅在流量处理实体（如Web缓存）上实现的功能
3. 在两端实施WCCP

本文档将检查以下三个WCCP运行特征：

1. 分配方法确定哪些WCCP流量以及为流量的目标选择哪些WCCP设备。WCCP协议支持多个设备集群在一起。
2. 当需要从流量流经的正常网络路径中进行更改时，重定向方法会将流量转发到WCCP设备。
3. 如果无法为流量提供服务，返回方法将确定如何将流量从WCCP设备发回路由器。如果WCCP设备为请求提供服务，则数据包会直接返回给请求者。

WCCP和Catalyst 6500

Catalyst 6500 Supervisor Engine 2、Supervisor Engine 32和Supervisor Engine 720支持以下WCCP功能和方法：

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

有关这些功能的详细信息，请参阅Cisco 6500系列Cisco IOS软件配置指南12.2SX中的配置WCCP。

WCCP分配方法

WCCP分配确定WCCP协议重定向的流量和接收重定向流量的WCCP实体。

当在路由器接口和WCCP实体上配置WCCP时，重定向设备(Catalyst 6500)需要知道要重定向哪些流量以及要将流量发送到何处。服务组集群中的WCCP实体都通过WCCP协议与Catalyst 6500通信；但是，选择一个WCCP设备来表示集群，以控制集群的运行方式（通过分配方法、重定向方法等）。 WCCP设备和路由器可以协商在服务组中的Web缓存之间分发数据包的方法。服务组定义为最多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引擎32或Supervisor引擎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利用率增加，因为每个流中的第一个数据包是软件交换的。
• 性能 — 将流量发送到CPU进行查找的速率受到限制，以保护CPU。
• NetFlow功能 — 如果NetFlow资源由WCCP使用，则使用NetFlow资源的其他功能可能会受到影响。

基于散列的软件处理分配要求导致的限制和影响适用于入口和出口流量。如果网络正在经历非典型流量模式(如拒绝服务(DoS)攻击)，则对CPU的影响可能会加剧。在典型的攻击或蠕虫爆发中，主机发送的每个数据包都发往新的目的地或端口，这会导致每个数据包在软件中进行处理。由于WCCP重定向流量被显式发送到CPU进行第一数据包处理，因此保护方法有限。在接口上使用“拒绝”ACL条目可以限制发送到CPU的流量；但是，没有针对这些类型的攻击的速率限制器或其他保护。

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

基于掩码的分配处理方式因配置在入口还是出口而异。

使用基于入口掩码的分配，在数据包转发之前将掩码编程到ACL TCAM中，因此不需要NetFlow表和软件处理。WCCP实体选择多个哈希桶，并为每个桶分配地址掩码和WCCP设备。一旦分配完成，管理引擎会为每个存储桶编程一个TCAM条目和一个硬件邻接关系，并通过L2重写将匹配地址掩码的数据包重定向到关联的WCCP设备。

如果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配置为出口功能，则掩码分配需要软件处理，这会否定基于掩码的分配方法的任何优点。

在两个基于掩码的选项中，只有基于入口掩码的分配能够为初始和后续数据包启用完全基于硬件的转发。任何其他选项（如使用基于哈希的分配或出口处理）都会导致初始数据包的软件交换和后续数据包的硬件NetFlow交换转发。

WCCP重定向方法

WCCP实体（而非Catalyst 6500）将哈希表和掩码/值集指定给Catalyst 6500，因此重定向方法的配置在该设备上完成，而不是在Catalyst 6500交换机上完成。Catalyst 6500根据与WCCP实体/组的WCCP通信确定可用的最佳重定向方法。此协商确定如何将重定向的流量转发到设备。有两个重定向选项：L3(GRE)和L2（MAC地址重写）。

使用WCCPv1时，唯一的选项是L3重定向，也称为GRE封装。使用L3重定向时，每个WCCP重定向数据包封装在标有协议类型0x883E的GRE报头中，后跟一个四八位组WCCP重定向报头，该报头随后被发送到WCCP设备（如缓存引擎）。

引入WCCPv2后，添加了L2重定向（也称为加速WCCP重定向），以利用Catalyst 6500等硬件交换平台。当WCCP使用L2重定向时，WCCP设备和Catalyst 6500必须是L2邻接（在同一L2 VLAN中）。 重定向的L2流量不使用GRE封装；相反，MAC目标地址由Catalyst 6500重写为连接L2的WCCP实体的MAC目的地址，并通过正常硬件交换转发。

注意：转发到WCCP设备的方法可能与WCCP设备将流量发回Catalyst 6500所使用的方法不同。WCCP用于协商两台设备都支持的转发和返回方法。请参阅WCCP返回方法。

L3(GRE)转发方法

WCCP L3操作涉及使用GRE作为封装方法。重定向数据包封装在协议类型为0x883e的GRE报头中，以及包含匹配的服务ID和哈希桶（仅WCCPv2）的4字节WCCP重定向报头。 使用GRE，WCCP客户端可通过多个L3（路由）跳从Catalyst 6500中分离。

在此场景中，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报头，这会强制所有流量进行软件交换。

使用基于哈希的分配方法，Supervisor引擎32和Supervisor引擎720转发软件中每个流的第一个数据包，以便建立NetFlow表条目。然后，数据包封装在GRE中（初始数据包的封装和转发在软件中完成），并转发到WCCP设备。

NetFlow条目的建立会影响CPU利用率，但后续数据包转发是在Supervisor引擎720和Supervisor引擎32的硬件中完成的。流量模式，特别是唯一流的数量，决定了CPU的利用率。如果Catalyst 6500的NetFlow资源被消耗，则所有流量都会在软件中转发。

Supervisor PFC的NetFlow资源在不同平台中不同。目前，Supervisor引擎720平台上的PFC-3BXL上提供了最大的NetFlow资源。

入口 — 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报头，这会强制所有流量进行软件交换。

Catalyst 6500使用基于哈希的分配方法和Supervisor引擎32和Supervisor引擎720，转发软件中每个流的初始数据包，以便建立NetFlow表条目。然后，数据包封装在GRE中并转发到WCCP实体。

NetFlow条目的建立会影响CPU利用率，但后续数据包转发是在硬件中完成的。流量模式，尤其是唯一流的数量，决定了CPU的使用量。如果Catalyst 6500的NetFlow资源被消耗，则所有流量都会在软件中转发。

Supervisor PFC的NetFlow资源在不同平台中不同。目前，Supervisor引擎720平台上的PFC-3BXL上提供了最大的NetFlow资源。

出口 — L3(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资源在不同平台中不同。目前，Supervisor引擎720平台上的PFC-3BXL上提供了最大的NetFlow资源。

L2转发方法

通过L2转发，服务组中的WCCP实体（ACNS、WAFS、WAAS等）属于同一子网，且与Catalyst 6500相邻的L2。这可实现流量的高吞吐量、低延迟重定向。入口接口（配置了WCCP的位置）和WCCP设备所在的接口必须位于不同的VLAN上。

注意：使用L2重定向时，数据包将被重写，源MAC设置为路由器，目的MAC设置为缓存引擎。此重定向方法的唯一缺点是缓存引擎必须可由Catalyst 6500访问L2，并且必须位于与已配置的入口WCCP接口不同的L3接口上。

注意：转发到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资源在不同平台中不同。目前，Supervisor引擎720平台上的PFC-3BXL上提供了最大的NetFlow资源。

入口 — 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资源在不同平台中不同。目前，Supervisor引擎720平台上的PFC-3BXL上提供了最大的NetFlow资源。

出口 — L2 +掩码分配

当在出口方向配置时，L2 +掩码分配会交换软件中每个流中的第一个数据包，就像L2 +哈希分配案例一样。后续数据包在硬件中进行NetFlow交换。

注意：NetFlow流掩码设置为接口全流模式，这可能会影响交换机上配置的其他NetFlow功能。

PFC2和PFC3不支持出口ACL邻接编程，这会强制软件处理每个流中的初始数据包；流中的后续数据包在硬件中转发。

NetFlow条目的建立会影响CPU利用率，但后续数据包转发是在硬件中完成的。流量模式（尤其是唯一流的数量）决定了CPU的利用率。如果Catalyst 6500的NetFlow资源被消耗，则所有流量都会在软件中转发。

Supervisor PFC的NetFlow资源在不同平台中不同。目前，Supervisor引擎720平台上的PFC-3BXL上提供了最大的NetFlow资源。

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

GRE返回

在早于12.2(18)SXH的Cisco IOS软件版本中，Catalyst 6500支持的唯一返回方法是GRE封装。除了附加到返回流量的GRE报头外，还附加了WCCP报头。虽然GRE在管理引擎32和管理引擎720硬件中本地受支持，但此附加报头会导致GRE不受硬件支持。请注意，Catalyst 6500和WCCP设备必须支持并协商L2返回方法。

管理引擎2中不存在任何GRE、入口、出口或WCCP返回的GRE硬件支持。为了处理此类GRE解封，Cisco IOS软件在启用WCCP的接口上对WCCP GRE隧道接收邻接进行编程，以指向路由处理器(RP)，这会导致软件处理返回流量。

在Catalyst 6500上使用重定向列表以避免可能需要通过GRE返回的流量是降低从WCCP实体发回的流量的软件处理要求的有效方法。这比在WCCP实体上拒绝流量并强制将其封装并发回Catalyst 6500更有效。

请记住，WCCP服务组是可扩展的。如果由于负载而绕过超额流量，则此流量会被发回，这会在Catalyst 6500上创建CPU负载。正确扩展甚至过度构建WCCP服务组是避免这种情况的唯一方法。

L2返回增强

在12.2(18)SXH中，一个选项允许WCCP实体重写L2 MAC地址，而不是封装返回流量。此L2返回增强功能(思科漏洞ID CSCuk59825)在将WCCP配置为使用入口重定向和掩码分配时启用返回流量的硬件处理。

WCCP选项摘要

在Catalyst 6500上实施时，WCCP提供许多配置选项，如下表所示。请注意，WCCP设备会协商这些选项并控制Catalyst 6500使用哪些选项。配置在WCCP连接的WCCP设备端完成。

从硬件角度来看，所有出口WCCP配置都需要软件处理并影响CPU利用率。使用基于哈希的分配方法时，在入口处也需要进行软件处理，这会对CPU利用率产生相同的潜在影响。

在Catalyst 6500上部署WCCP的推荐方法是使用掩码分配的L2重定向，如果可用，返回L2。

提示：只有一个选项可确保高性能、完全基于硬件的转发：基于入口的L2重定向，在Supervisor引擎2、Supervisor引擎32和Supervisor引擎720上分配掩码。

WCCP设计建议

使用这些配置建议，以便您能够根据您的情况确定最佳的WCCP部署方法。

摘要

设计网络，使WCCP入口可用作重定向方法。一种好的设计方法是将缓存交换块作为分层L3分布网络的一部分；这可确保在几个主要入口端口识别WCCP服务流量。

• 使用12.2(18)SXF7或更新的Cisco IOS软件。
• 识别和重定向入口接口上的流量。
• 使用支持L2重定向方法的WCCP设备。
• 使用支持基于掩码的分配方法的WCCP设备。
• 如果可能，请在Catalyst 6500上使用重定向列表来处理无法由WCCP设备提供服务的流量。
• 调整NetFlow计时器，使用出口或任何基于哈希的分配配置（使用Supervisor引擎720）。
• WCCP设备应具有专用的L3环境和SVI/VLAN接口。

此外，思科高级服务还建议考虑以下设计注意事项：

• 在具有掩码分配的不完全L2重定向的环境中，Supervisor引擎720的性能不比Supervisor引擎2平台好。请勿升级硬件，并期望在此情况下获得更好的性能。
• 对于具有高流量要求的大型中心站点部署，请考虑采用策略型路由(PBR)和思科内容交换模型(CSM)/应用控制引擎(ACE)的设计，以实现流量拦截和转发。
• WCCPv2在完全情况下按预期运行。但是，在某些情况下，路由器上的CPU使用率可能会达到导致设备不可用和需要重新加载的较高水平：
  
  
  • WCCPv2从入口硬件加速的基于L2掩码的分配模式回退到需要MSFC上CPU的任何其他模式。
  • WCCP配置错误（例如，出口而非入口或L2哈希而非掩码分配）。
• 在完全生产部署之前，任何使用Catalyst 6500（缓存、流、WAAS或其他“高流量速率”方案）的高容量WCCP部署都应通过实时流量测试性能。

其他建议

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

如果使用除入口L2掩码分配以外的任何方法，则Supervisor引擎720平台上的NetFlow资源可以快速耗尽。Supervisor引擎720无法通过任何其他方法提供比Supervisor引擎2更好的性能。

在非优化设计中必须使用Supervisor引擎720或Supervisor引擎32的情况下，请考虑使用mls ip netflow creation software-mode fast命令，以便可以加快WCCP初始数据包的NetFlow处理。这将删除添加到Supervisor引擎32和Supervisor引擎720 NetFlow的增强功能，并提供与Supervisor引擎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 aging fast time 3 threshold 1
• mls aging long 64
• mls aging normal 32
• mls ip netflow creation software-mode fast（这会禁用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-only或dst-only。

在12.2(18)SXF5中为Supervisor引擎2和L2返回添加了WCCP支持。在2007年4月/5月的12.2(18)SXH之前，Supervisor引擎720中未添加WCCP支持。

Cisco IOS软件服务器负载均衡(SLB)仅支持WCCP L2 PFC重定向；其他WCCP配置不兼容，GRE不起作用。WCCP acceleded命令仅适用于Supervisor引擎2/MSFC2。其目的是强制路由器协商掩码分配和L2重定向，这意味着所有WCCP重定向都在硬件中完成。管理引擎32和管理引擎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引擎2平台使用acceled命令。

重定向列表用于标识应选择或未选择用于重定向的流量。回想一下，此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 ip wccp service-number — 提供“重定向的数据包总数”计数。此计数是重定向的流数或会话数。
• show ip wccp service-number detail — 提供“Packets Redirected”计数。count是重定向的流或会话数。
• show ip wccp web-cache detail — 提供使用L2重定向的流数（而非数据包数）的指示。
• 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命令

当您有需要使用NetFlow硬件资源的WCCP配置时，请使用以下多层交换(MLS)和交换矩阵管理器(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缺陷

此Cisco Bug ID和解决方案表支持使用Cisco IOS软件版本12.2(18)SXF7或更高版本以获得WCCP最佳支持的一般建议。

修订历史记录