本文描述如何使用在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实际上介入三个组件:
本文检查这三种WCCP运行特性:
Catalyst 6500 Supervisor引擎2、Supervisor引擎32和Supervisor引擎720支持这些WCCP功能和方法:
欲了解更详细的信息在这些功能,参考配置在Cisco 6500系列Cisco IOS软件配置指南的WCCP, 12.2SX。
WCCP分配确定哪个流量WCCP协议重定向,并且哪个WCCP实体收到重定向的数据流。
当WCCP配置在路由器的接口和在WCCP实体时,重定向的设备(Catalyst 6500)需要了解什么流量将重定向,并且流量将发送的地方。WCCP实体在服务组内集群全部通过WCCP协议通信用Catalyst 6500;然而,一个WCCP设备选择代表集群为了控制集群如何运行(用分配方法,重定向方法,等等)。WCCP设备和路由器可能协商数据包在服务组中被分配在Web缓存之间的方法。服务组定义作为32路由器和32个WCCP实体之间的一越来越多的关系。协商是由服务组;因此,参加几服务组的Web缓存可能协商每服务组的一个不同的分配方法。现在可以得到的WCCP服务是:
WCCP服务 | 协议 |
Web缓存 | HTTP |
53 | DNS缓存 |
60 | FTP |
61 | WAAS -转发 |
62 | WAAS -反向 |
70 | HTTPS |
80 | 实时流协议 (RTSP) |
81 | Microsoft媒体服务器(MMS)在UDP (MMSU) |
82 | 在TCP (MMST)的MMS |
83 | RTSP使用UDP (RTSPU) |
89 | CIFS缓存WAAS |
98 | 自定义Web缓存 |
99 | 反向代理 |
90-97 | 用户可配置的* |
*用户可配置的服务在有一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 :
所有设备在WCCP服务组内必须使用同一个分配方法。在WCCP实体配置并且Catalyst 6500了解分配方法。参考的WCCP设计建议欲了解更详细的信息。
基于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的分配方法影响这些功能:
软件处理的基于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硬件。
两个基于掩码的选项,仅入口掩码根据初始和后续信息包的分配enable (event)全双工基于硬件的转发。所有其它选项,例如处理使用基于HASH的分配或的出口,导致后续信息包初始数据包和硬件Netflow交换的转发的软件交换。
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 L3操作介入使用GRE作为封装方法。重定向的数据包在与0x883e协议类型的一个GRE报头被封装,与包括匹配的服务ID和哈希桶的4字节WCCP重定向报头一起(仅WCCPv2)。使用GRE启用从Catalyst 6500将分离的WCCP客户端由多L3 (路由)跳。
在此方案中,选项可用为WCCP重定向包括:
在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。
在Supervisor引擎2上,每GRE数据包发送对处理的MSFC。因为硬件方面不支持GRE封装, MSFC必须应用GRE和WCCP报头,强制所有流量的软件交换。
使用基于掩码的分配方法, Supervisor引擎32和Supervisor引擎720转发初始和后续信息包在硬件方面,因为本地支持GRE和掩码分配使用ACL TCAM硬件转发。
在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。
在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转发, WCCP实体(ACNS、WAFS, WAAS,等等)在服务组内是相同子网的一部分并且是L2在Catalyst 6500附近。这启用高吞吐量,流量的低延时重定向。入口接口(其中WCCP配置)和WCCP设备查找的接口必须在不同的VLAN。
选项可用为WCCP重定向在此方案包括:
当配置在入口与L2 +哈希分配, WCCP流量发送在每个流的第一数据包是交换的软件,在硬件Netflow表里创建一个Netflow条目。
因为WCCP是一无状态的机制,信息在软件方面没有维护;相反,它在硬件方面在Netflow表里维护作为条目。只要Netflow条目存在,在流的后续的流量在硬件方面转发。
Netflow条目的建立影响CPU利用率,但是后续信息包转发在硬件方面完成。流量模式,唯一流特别是数量,指明多少使用CPU。如果Catalyst 6500的Netflow资源浪费,则所有流量在软件方面转发。
Supervisor PFC的Netflow资源在多种平台间有所不同。目前,最大的Netflow资源是可用的在Supervisor引擎720平台的PFC-3BXL。
当配置在入口,是支持L2 +掩码分配Catalyst 6500最高效的WCCP方法。所有流量是硬件交换,包括在每个流的初始数据包。软件重定向没有要求;硬件提供初始和后续信息包转发。
在所有WCCP数据包接收前, Catalyst 6500的硬件ACL TCAM资源用于为了预编程序硬件条目。
为了使用此方法和使用全双工硬件交换, WCCP实体必须也支持L2重定向和基于掩码的分配方法。此方法的配置在WCCP实体完成,在与WCCP实体/组的WCCP初始通信期间,并且Catalyst 6500协商佳方法。
使用出口L2 +哈希分配, WCCP流量发送在每个流的第一数据包是交换的软件,在硬件Netflow表里创建一个Netflow条目。
另外,当配置在输出方向,另外的转发信息库(FIB)查找在流的第一数据包要求为了确定邻接关联与CE,要求在Catalyst 6500内的数据包再通行。后续信息包是在硬件方面交换的Netflow。
Netflow条目的建立影响CPU利用率,但是后续信息包转发在硬件方面完成。流量模式,唯一流特别是数量,指明多少使用CPU。如果Catalyst 6500的Netflow资源浪费,则所有流量在软件方面转发。
Supervisor PFC的Netflow资源在多种平台间有所不同。目前,最大的Netflow资源是可用的在Supervisor引擎720平台的PFC-3BXL。
当配置在输出方向, L2 +掩码分配转换在每个流的第一数据包在软件方面,正如L2 +哈希分配案件。后续信息包是在硬件方面交换的Netflow。
PFC2和PFC3不支持出口编程ACL的邻接,强制处理为在每个流的初始数据包的软件;在流的后续信息包在硬件方面转发。
Netflow条目的建立影响CPU利用率,但是后续信息包转发在硬件方面完成。流量模式,唯一流特别是数量,指明多少使用CPU。如果Catalyst 6500的Netflow资源浪费,则所有流量在软件方面转发。
Supervisor PFC的Netflow资源在多种平台间有所不同。目前,最大的Netflow资源是可用的在Supervisor引擎720平台的PFC-3BXL。
当WCCP用于拦截流量时,并且WCCP实体执行在那些数据包的一完整操作,数据包然后准备被退还的对从WCCP设备的客户端。此通常处理的流量,是注定的回到网络的客户端,不要求任何特殊封装,当发送出于WCCP设备上一步往客户端。
由于WCCP拦截导致顺利地被服务的客户端的要求(从缓存的文件,从缓存的已分解从WAAS的数据流,文件),可以被退还的到网络作为与目的地址的正常流量在是的数据包原始申请人。如果在从WCCP设备的网络路径给客户端,此流量可以通常是L3/switched由Catalyst 6500;使用L2附加的WCCP设备,流量在网络路径。因为目的地当前是原始客户端而不是在互联网或内联网的一个服务器封装不是需要的为了发送它回到从WCCP设备到Catalyst 6500。网络在Catalyst 6500然后处理此类似所有其他IP数据流并且使用硬件转发为了返回请求的流量对客户端。
有时WCCP实体不可执行请求的操作的地方, WCCP设备可能需要送回流量到Catalyst 6500和保留数据包的原始目的地。转发从WCCP实体的此流量没有封装可能导致流量环路。为了隐藏从客户端的一不成功服务尝试和发送数据包到将被服务的原始目的地,数据包一定保持不可更改,被放置回到他们的原始转发路径,并且转发,不用对原始目的地的WCCP拦截。
在WCCP返回方法, WCCP可以用于封装这些数据包,送回他们到首先拦截他们,剥去所有封装,并且放置他们回到转发路径他们被拦截的设备。通常将发送的这些数据包需要,好象WCCP未曾拦截他们。
这些案件示例包括:
此时,可以用GRE封装仅完成和任何Catalyst 6500硬件方面不支持此回归方法。如果很多流量被退还的到有此方法的Catalyst 6500,高CPU利用率也许发生,因为此流量在软件方面处理。在Cisco IOS软件版本12.1(18)SXH中,有Catalyst 6500硬件支持的L2返回方法。
在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服务组是避免此情况的唯一的方法。
在12.2(18)SXH中,选项允许WCCP实体重写L2 MAC地址而不是封装回程数据流。此L2返回增强(Cisco Bug ID CSCuk59825)启用硬件处理返回的流量,当WCCP配置以掩码分配时使用入口重定向。
如此表所显示,当实现在Catalyst 6500, WCCP提供许多配置选项。注意WCCP设备协商Catalyst 6500使用选项的这些选项和控制。配置在WCCP连接的WCCP设备侧被执行。
重定向方法 | 分配 方法 |
进入 出口 |
交换结果 |
L2 | 哈希 | 入口 | 软件处理 |
L2 (建议使用) | 掩码 | 入口 | 处理与ACL TCAM的全双工硬件 |
L2 | 哈希 | 出口 | 软件处理 |
L2 | 掩码 | 出口 | 软件处理 |
GRE | 哈希 | 入口 | 软件处理 |
GRE (PFC3或更新) | 掩码 | 入口 | 处理与Netflow的全双工硬件全流 |
GRE | 哈希 | 出口 | 软件处理 |
GRE | 掩码 | 出口 | 软件处理 |
从硬件方面,所有出口WCCP配置要求处理的软件并且影响CPU利用率。当使用基于HASH的分配方法并且导致在CPU利用率时的同一潜在影响软件处理在入口也要求。
WCCP部署推荐的方法在Catalyst 6500的是L2与掩码分配,当联机, L2返回的重定向。
请使用这些配置推荐,因此您能确定WCCP部署佳方法您的情况的。
设计网络这样WCCP入口可以使用作为重定向方法。遵循好的设计方法将有高速缓冲存储switchblock作为分层的一部分, L3分布式网络;这保证WCCP服务流量可以在一些主要入站端口识别。
另外,思科高级服务推荐这些设计注意事项:
请使用重定向列表在交换机为了避免被退还的到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)配置掩码分配的是:
请使用这些命令为了查看Netflow利用率和确定WCCP是否用完Netflow条目和使用软件处理:
如果遇到WCCP软件问题,因为Netflow资源浪费,这些命令积极地可能清楚现有项和创建新的条目的空间。(这不帮助,如果有完全更多条目比有Netflow空间。)
要避免丢包, WCCP实体必须重定向流量在不是接口的接口外面WCCP配置。在这种情况下,当所有情况符合时, Catalyst 6500 WCCP丢弃数据包:
此情况是由安装的保护机制造成的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协商此,不用对此命令的需要。
对于标准的透明缓存重定向,请收回WCCP实体提供WCCP路由器支持的方法,并且可能需要配置如此执行。对于Cisco ACNS,此配置示例请求优化L2-redirect和基于掩码的分配方法:
ContentEngine(config)# wccp version 2
ContentEngine(config)# wccp router-list 1 172.16.16.1
ContentEngine(config)# wccp service router-list-num 1 l2-redirect mask assign
从路由器端, Catalyst 6500设计应该保证WCCP设备在不在当前流量的路径的一个专用的L3接口(入口或出口)。对于硬件性能,通信流应该捕获的入站到Catalyst 6500,即使这要求更多接口的配置比,如果单个出口接口选择。一理想的设计在到达此设备前将聚集所有流量,并且仅一些个接口将要求WCCP入口配置。
在Catalyst 6500的WCCP配置应该是:
6500Switch# ip wccp version {1 | 2}
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设备 | wccp version 2 |
WCCP路由器: 全局 |
ip wccp version 2 |
WCCP路由器: 每入口接口 |
ip wccp redirect service in |
要检查此配置,请输入此命令:
Show ip wccp service detail
对于另外的WCCP配置选项,例如组寻址使用组播或另外的WCCP安全,参考配置Web缓存服务使用WCCP。
当您使用WCCP和硬件转发时,一些计数器可能不显示正如所料:
当您有要求使用Netflow硬件资源的WCCP配置时,请使用这些多层交换和组织管理器(FM)命令,因此您能查看Netflow资源的状况:
Cisco Bug ID和解决方法此表支持一般建议使用Cisco IOS软件版本12.2(18)SXF7或以上为WCCP最好的支持。
Cisco Bug ID | 解决在Cisco IOS软件版本 | 详细信息 |
CSCsd20327 | 12.2(18)SXF7 | 服务的90 WCCP上升和下降,并且导致WCCP服务损耗。当服务81, 82和90配置时,此问题发生。数据包踪迹表明路由器也许回应到‘从缓存的Here_I_Am’消息有‘包含一不正确目的IP地址的I_see_you’消息的。 |
CSCsa77785 | 12.2(18)SXF6 | 当您使用WCCP L2重定向并且屏蔽与一招待基础的标准ACL的分配模式作为WCCP重定向ACL时,重新加载也许发生。 |
CSCse69713 | 12.2(18)SXF6 | 当所有缓存时引擎在WCCP服务组中在软件方面丢失,流量处理而不是交换式在硬件方面。 |
CSCsd28870 | 12.2(18)SXF5 | 在WCCP重定向ACL列表,配置与日志关键字的ACE没有被编程到TCAM表。 |
CSCsb61021 | 12.2(18)SXF5 | 高CPU利用率在Supervisor引擎720或Supervisor引擎32也许发生,当IP伪装功能在Cache Engine时配置,并且,当WCCP重定向在输出方向时配置。从Cache Engine的IP被伪装的数据包,与客户端或服务器的目的地,在软件方面交换而不是硬件。 作为应急方案,请使用in命令ip WCCP服务的重定向入站和出站接口。 |
CSCsb21972 | 12.2(18)SXF2 | 当配置的WCCP和NDE,您也许发现校正错误造成的许多traceback,并且CPU利用率也许难以承认地高。 |
CSCeh85087 | 12.2(18)SXF | 当有用户配置的‘deny ip any any’在WCCP重定向ACL时,并且,当许多WCCP服务组被服务时,流量关联与一些服务组没有重定向到CE路由器。 |
CSCeh56916 | 12.2(18)SXF | 当WCCP服务启用时,当掩码分配配置作为分配方法时,并且,当五个或多个缓存在服务组中时,协议消息传送到缓存可能溢出和引起存储器损坏和重新加载。 |
CSCsb18740 | 12.2(18)SXF和SXE6 | 在基于Gre的转发模式, WCCP不必要地使用增加MSFC CPU利用率的一个软件缓存。 |
CSCsb26773 | 12.2(18)SXF | 入站ACL也许造成WCCP重定向失效与所有重定向的数据流损耗。 |
CSCsa90830 | 12.2(18)SXE2 | WCCP,当Cache Engine为转发同掩码分配模式时的GRE配置入口重定向的流量使用Netflow表硬件交换。当Netflow表全双工时, WCCP入口重定向发生故障。 |
CSCec55429 | 12.2(18)SXE | WCCP服务组列表按服务组创建的顺序被扫描,而不是由优先级。如果多个动态WCCP服务定义,匹配的选择标准的流量超过一服务组没有重定向给有最高优先级的服务组。 |
CSCuk50878 | 12.2(18)SXE | 在Cisco Bug ID CSCec55429是解决的版本中,在一定数量的WCC ‘缓存丢失的’和‘缓存被找到的’事件为所有缓存在服务组中后发生,这些事件可能发生:
|
CSCsa67611 | 12.2(18)SXE | 在非MPLS接口的流入多协议标签交换(MPLS)数据包(对IP路径的标记退出)例如输出功能配置(出口ACL或出口WCCP)也许没有应用的输出功能。因为输出ACL查找绕过,此问题发生。 |
CSCeh13292 | 12.2(18)SXD4 | WCCPv2的配置在Supervisor引擎720的导致高CPU利用率。 |
CSCeb28941 | 12.2(18)SXD1 | 网络地址转换(NAT)不与配置的WCCP一起使用。 |
CSCed92290 | 12.2(17d)SXB2 | 没有下个跳越地址解析服务(ARP)缓存条目的WCCP重定向的数据包是交换的进程生成ARP请求。由于WCCP重定向,然而, ARP请求没有发送, ARP缓存为下一跳从未填充,并且随后的WCCP重定向的数据包继续是交换的进程。 |
CSCuk59825 | 12.2(17d)SXF5 Sup720的-Sup2 Whitney1.0 | L2回程数据流的此Cisco IOS软件版本已添加硬件支持。WCCP请求的注释指定L2返回作为协商的一个可选功能在路由器和缓存之间。直到现在,因为必需的硬件支持是缺少的,在Cisco IOS软件的WCCP未允许此功能的协商。支持当前是可用,因此L2返回的协商在路由器之间的WCCP协议交换和缓存可以启用。 |