Switches : Switches Cisco Catalyst de la serie 6500

WCCP en las Plataformas del Catalyst 6500 con CPU elevada la guía de configuración de la utilización

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios

Introducción

Este documento describe cómo utilizar el protocolo web cache communication (WCCP) en la plataforma de las Cisco Catalyst 6500 Series.

El WCCP fue diseñado originalmente como método para interceptar el tráfico de la Web (HTTP) y delantero él caché local a un dispositivo, donde podría ser servido a un cliente de una ubicación local y conservar el ancho de banda WAN costoso.

De una perspectiva del usuario de la red, el WCCP es transparente porque es utilizado en el nivel de red, sin ninguna configuración especial por el usuario, para identificar y reorientar el tráfico de la Web que atraviesa un dispositivo de la capa 3 (L3) caché local a un dispositivo. Aunque el WCCP fuera diseñado originalmente para el tráfico de la Web, el método transparente de cambio de dirección se ha convertido en un mecanismo muy útil para abordar otros problemas con el contenido en grandes cantidades sobre los links de poco volumen. Por este motivo, el soporte a protocolo adicional fue agregado a versiones de WCCP posteriores. Estas Tecnologías adicionales incluyen los protocolos tales como HTTP, HTTPS, FTP, flujo de datos de video, y archivo que oculta las Tecnologías, tales como el Common Internet File System (CIFS). Estas soluciones de Cisco y Plataformas del soporte de Tecnologías más nuevas, tales como Wide Area File Services (WAFS), el Wide Area Application Services (WAAS), aplicación orientaron el establecimiento de una red (AONs), y las capacidades mejoradas del Application and Content Networking Software (ACNS).

La adopción WCCP está aumentando como las empresas implementan las últimas herramientas de la productividad tales como comunicaciones y entrenamiento de video, así como vive y a pedido vídeo. Esfuerzos para controlar los costes, tales como centros de datos consolidados, crean la necesidad del WCCP de soportar adicional, los servicios del ancho de banda de la extremadamente alta.

Debido a la importancia del WCCP con las redes ricas contentas de hoy, algunas Plataformas, tales como el Catalyst 6500, han implementado el funcionamiento asistido por hardware con el WCCP para reducir carga de la CPU requerido para el protocolo. Este documento describe cómo desplegar el WCCP en el Catalyst 6500 para maximizar la utilización del hardware y reducir carga de la CPU.

Contribuido por Rahul Parameswaran y Dixon Ho, ingenieros de Cisco TAC.

Prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

  • WCCP
  • Cisco Catalyst 6500 Series Switch
  • Cisco IOS ® Software

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

  • Cisco Catalyst 6500 Series Switches
  • Cisco IOS Software Release 12.1(50)SY o Posterior con el Supervisor Engine 2T (Policy Feature Card 4)
  • Cisco IOS Software Release 12.2(18)SXD1 o Posterior con el Supervisor Engine 720 (Policy Feature Card 3)

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Descripción general funcional WCCP

Las funciones que genéricamente se refieren mientras que el WCCP implica realmente tres componentes:

  1. Funciones implementadas solamente en el router o el Switch
  2. Funciones implementadas solamente en la entidad del procesamiento del tráfico, tal como a caché Web
  3. WCCP implementado en los ambos lados

Este documento examina estas tres características de funcionamiento WCCP:

  1. El método de asignación determina que tráfico WCCP y que se elige el dispositivo WCCP para el destino del tráfico. Los dispositivos múltiples de los soportes a protocolo WCCP agrupados juntos.
  2. El método de redireccionamiento adelante el flujo de tráfico al dispositivo WCCP cuando hay una necesidad de cambiar de la trayectoria de red normal que el tráfico atravesaba.
  3. El método de vuelta determina cómo el tráfico se devuelve al router de la aplicación WCCP si el tráfico no podría ser mantenido. En caso de que el dispositivo WCCP mantenga la petición, los paquetes se vuelven directamente al solicitante.

WCCP y Catalyst 6500

El soporte del motor 2, del Supervisor Engine 32, y del Supervisor Engine 720 del Catalyst 6500 Supervisor estas características y métodos WCCP:

  • Versión de WCCP 2 (WCCPv2)
  • método de asignación Hash-basado
  • Método de asignación basado en máscaras (acelerado por hardware)
  • Método de redireccionamiento del Generic Routing Encapsulation (GRE) L3 (acelerado por hardware en el Supervisor Engine 32 y el Supervisor Engine 720)
  • Método de redireccionamiento de la capa 2 (L2) (acelerado por hardware en el Supervisor Engine 2, el Supervisor Engine 32, y el Supervisor Engine 720)
  • Método de la vuelta GRE
  • Método de la vuelta L2 con el Cisco IOS Software Release 12.2SXH (acelerado por hardware en el Supervisor Engine 2, el Supervisor Engine 32, y el Supervisor Engine 720)

Para más detalles en estas características, refiera a configurar el WCCP en la guía de configuración del Cisco IOS Software de las Cisco 6500 Series, 12.2SX.

Método de asignación WCCP

La asignación WCCP determina que trafican el protocolo WCCP reorienta y que recibe la entidad WCCP el tráfico redirigido.

Cuando el WCCP se configura en una interfaz de un router y en una entidad WCCP, está ser enviado las necesidades de reorientación del dispositivo (el Catalyst 6500) de saber qué tráfico debe ser reorientado y donde el tráfico. Las entidades WCCP dentro de un grupo de servicios agrupan todas comunican con el protocolo WCCP con el Catalyst 6500; sin embargo, un dispositivo WCCP se selecciona para representar el cluster para controlar cómo el cluster actúa (por el método de asignación, el método de redireccionamiento, y así sucesivamente). El dispositivo y el router WCCP pueden negociar el método por el cual los paquetes son distribuidos entre los cachés de red en un grupo de servicios. Definen a un grupo de servicios como relación múltiple entre hasta los 32 Router y 32 entidades WCCP. La negociación está por el grupo de servicios; así, los cachés de red que participan en varios grupos de servicios pueden negociar un diverso método de asignación para cada grupo de servicios. Los servicios actualmente disponibles WCCP son:

Servicio WCCPProtocolo
caché WebHTTP
53Caché DNS
60FTP
61WAAS - remita
62WAAS - invierta
70HTTPS
80Real-Time Streaming Protocol (RTSP)
81Servidor de medios de Microsoft (MMS) sobre UDP (MMSU)
82MMS sobre TCP (MMST)
83RTSP usando UDP (RTSPU)
89CIFS-caché WAAS
98Aduana caché Web
99Representación inversa
90-97Utilizador configurable *

* Implementan a los servicios utilizador configurables en el Catalyst 6500 con un comando interface level aplicado al dirección entrante o saliente. Las implicaciones de la opción de entrante o de saliente se discuten más adelante, pero entrante es el método preferido porque una lista de la reorientación se puede juntar con el WCCP para el rendimiento del hardware máximo.

Configurado una vez para el WCCP, un router hace publicidad de los métodos de asignación soportados para un grupo de servicios en los mensajes de las comunicaciones WCCP. La ausencia de tal mensaje implica que el Catalyst 6500 soporta el método de asignación hash-basado predeterminado solamente.

Una vez la negociación entre el Catalyst 6500 y el dispositivo WCCP es completa, la entidad señalada WCCP, con el WCCP, informa al Catalyst 6500 qué tráfico debe ser reorientado y a qué entidades WCCP se asigna el tráfico. Como un ejemplo, la entidad WCCP puede informar al Catalyst 6500 para reorientar todo el tráfico de la Web de una subred determinada para ocultar los motores 1 - 4 en el grupo de servicios cuando hay más de cuatro dispositivos WCCP disponibles.

Hay dos métodos de asignación disponibles para el WCCP:

  1. la asignación Hash-basada (valor por defecto) utiliza un algoritmo de troceo basado en software junto con las directivas de la aplicación WCCP-señalada para determinar que la aplicación WCCP recibe el tráfico. En una plataforma del Supervisor Engine 32 o del Supervisor Engine 720, utilizan a los Recursos de hardware del Netflow para aplicar un cierto nivel de asistencia por hardware.
  2. La asignación basada en máscaras utiliza las capacidades del hardware del Catalyst 6500, específicamente el Ternary Content Addressable Memory del Access Control List (ACL) (TCAM), para asignar el tráfico a las entidades WCCP. Éste es el método preferido.

Todos los dispositivos dentro de un grupo de servicios WCCP deben utilizar el mismo método de asignación. Los métodos de asignación se configuran en la entidad WCCP y son aprendidos por el Catalyst 6500. Refiera a las recomendaciones sobre diseño WCCP para más detalles.

Detalle Hash-basado del método de asignación

El mecanismo hash-basado de la asignación confía en un algoritmo realizado en el software. Para leverage el algoritmo de troceo, el primer paquete en un flujo determinado se envía del trayecto del hardware al trayecto por software en donde se realiza el hash.

El software realiza un hash XOR de los diversos componentes del flujo y sube con un hash que parta los flujos de tráfico a las diversas entidades WCCP. El mecanismo del hash determina cómo el tráfico se distribuye entre las entidades disponibles WCCP.

El resultado del hash se programa en la tabla del Netflow del hardware donde los paquetes subsiguientes en ese flujo se remiten. Sin importar los campos disponibles para desmenuzar por el WCCP, se utiliza el cinco-tuple completo. Esto significa que el Netflow está puesto en la interfaz, modo flujo completo cuando se habilita el WCCP. Esto tiene implicaciones en las otras funciones que pueden requerir los recursos del Netflow. Vea la sección de los defectos WCCP para más detalles.

Una pregunta común sobre el WCCP en el Catalyst 6500 es, “porqué hace el aumento de la utilización de la CPU cuando habilito el WCCP?” Cuando las asignaciones hash-basadas son funcionando, el proceso basado en software del paquete inicial en cada flujo pone una carga en el CPU y es lo más a menudo posible la causa de la utilización creciente. Con el hardware para reenvío actualmente disponible del Policy Feature Card 3 (PFC3), si el WCCP se configura como característica de la salida o si la asignación hash-basada es funcionando (ingreso o salida), un cierto nivel de proceso del software se requiere siempre.

El uso del método de asignación hash-basado afecta estas características:

  • Tabla del Netflow - El número de entradas soportadas por el PFC es limitado, y los cambios de la máscara del flujo interconectar a todo régimen para la tabla entera del Netflow.
  • Utilización de la CPU - Hay un aumento en la utilización de la CPU pues el primer paquete en cada flujo es conmutado por software.
  • Funcionamiento - La tarifa en la cual el tráfico se envía al CPU para las operaciones de búsqueda es limitada para proteger el CPU.
  • Características del Netflow - Las otras funciones que utilizan los recursos del Netflow pudieron ser afectadas si los recursos del Netflow son consumidos por el WCCP.

Las limitaciones y las implicaciones causadas por el requisito hash-basado de la asignación para el proceso del software son aplicables al ingreso y al tráfico de salida. El impacto en el CPU se puede exacerbar si la red está experimentando a los patrones de tráfico anormales, tales como un ataque de Negación de servicio (DoS). En un brote típico del ataque o del gusano, cada paquete enviado por un host está a un nuevo destino o puerto, que hacen cada paquete ser procesados en el software. Puesto que el tráfico redirigido WCCP se está enviando explícitamente al CPU para el primero-paquete que procesa, hay métodos de protección limitados. El uso de “niega” las entradas ACL en la interfaz puede limitar qué se envía al CPU; sin embargo, no hay tarifa-limitadores u otras protecciones contra estos tipos de ataques.

Detalle basado en máscaras del método de asignación

La asignación basada en máscaras es diverso dependiente dirigido sobre si está configurada en el ingreso o en la salida.

Con la asignación basada en máscaras del ingreso, la máscara se programa en el ACL TCAM antes del reenvío de paquete, así que el proceso de la tabla y del software del Netflow no es necesario. La entidad WCCP elige varios hash-compartimientos y asigna una máscara de dirección y el dispositivo WCCP a cada compartimiento. Una vez que las asignaciones son completas, el supervisor programa una entrada TCAM y una adyacencia del hardware para cada compartimiento y reorienta los paquetes que hacen juego a la máscara de dirección al dispositivo asociado WCCP mediante una reescritura L2.

Si el WCCP se configura como característica del ingreso, puede utilizar una entrada de la reorientar-adyacencia ACL en la tabla del hardware ACL. Una vez que el WCCP hace juego la entrada, utiliza una adyacencia apropiada para realizar cualquier una reescritura L2 o una encapsulación GRE. Así, cuando la asignación de la máscara se utiliza en el ingreso, la reescritura L2 (Supervisor Engine 2, Supervisor Engine 32, y Supervisor Engine 720) y encapsulación GRE (Supervisor Engine 32 y Supervisor Engine 720 solamente) se realizan en hardware.

Si el WCCP se configura como característica de la salida, las reorientar-adyacencias ACL no se soportan en hardware porque los paquetes en el flujo han sido ruteados ya por el sistema. El primer paquete de un flujo se envía al software para procesar. Una vez que se determina la reorientar-adyacencia apropiada, se programa en el hardware del Netflow (en vez de ACL TCAM), donde los puntos de entrada a una adyacencia que realice cualquier una reescritura L2 o una encapsulación GRE. Los paquetes subsiguientes en el flujo son reorientados en hardware por el hardware del Netflow.

Nota: Si el WCCP se configura como característica de la salida, la asignación de la máscara requiere el software que procesa, que niega cualquier ventaja del método de asignación basado en máscaras.

De las dos opciones basadas en máscaras, solamente la asignación basada en máscaras del ingreso habilita la expedición basado en hardware completa para la inicial y los paquetes subsiguientes. Cualquier otra opción, tal como el uso de la asignación hash-basada o salida que procesa, causa la transferencia del software del paquete inicial y de la expedición conmutada hardware-Netflow de los paquetes subsiguientes.

Método del redireccionamiento de WCCP

La entidad WCCP, no el Catalyst 6500, dicta las tablas de hash y la máscara/los valores establecidovalores establecidos al Catalyst 6500, así que la configuración del método de la reorientación se hace en ese dispositivo, y no en el Catalyst 6500 Switch. El Catalyst 6500 determina el mejor reorienta el método disponible, sobre la base de las comunicaciones WCCP con la entidad/el grupo WCCP. Esta negociación determina cómo el tráfico redirigido se remite a la aplicación. Hay dos opciones del cambio de dirección: (GRE) L3 y L2 (reescrituras de la dirección MAC).

Con el WCCPv1, la única opción es el cambio de dirección L3, también conocido como encapsulación GRE. Con el cambio de dirección L3, cada paquete reorientado WCCP se encapsula en un encabezado GRE marcado con un Tipo de protocolo 0x883E seguido por un cuatro-octeto que el WCCP reorienta la encabezado, que se envía posteriormente al dispositivo WCCP (tal como un motor del caché).

Con la introducción de WCCPv2, el cambio de dirección L2, también conocido como redireccionamiento de WCCP acelerado, fue agregado para aprovecharse de las Plataformas del Hardware Switching tales como el Catalyst 6500. Cuando el WCCP utiliza el cambio de dirección L2, el dispositivo y el Catalyst 6500 WCCP deben ser L2 adyacente (dentro del mismo VLA N L2). El tráfico reorientado L2 no utiliza la encapsulación GRE; en lugar, el Catalyst 6500 reescribe a la de la entidad L2-connected WCCP y se remite a la dirección destino MAC con el Hardware Switching normal.

Nota: El método de expedición al dispositivo WCCP puede no ser el mismo método que el dispositivo WCCP utiliza para enviar el tráfico de nuevo al Catalyst 6500. El WCCP se utiliza para negociar un método delantero y de vuelta que ambos dispositivos soporten. Vea el método de la vuelta WCCP.

Método de reenvío del (GRE) L3

116134-config-wccp-6500-01.jpg

La operación WCCP L3 implica el uso del GRE como método de encapsulación. Los paquetes reorientados se encapsulan en un encabezado GRE con un Tipo de protocolo de 0x883e, junto con una encabezado del redireccionamiento de WCCP 4-byte que incluya un compartimiento del ID del servicio y del hash correspondido con (WCCPv2 solamente). El uso del GRE habilita al cliente WCCP que se separará del Catalyst 6500 por los saltos (ruteados) múltiples L3.

En este escenario, las opciones disponibles para el redireccionamiento de WCCP incluyen:

  1. Ingreso - Cambio de dirección del (GRE) L3 + asignación del hash; esto requiere el proceso del software.
  2. Ingreso - Cambio de dirección del (GRE) L3 + asignación de la máscara; esto requiere el hardware lleno que procesa y está disponible solamente en el Supervisor Engine 32 o el Supervisor Engine 720.
  3. Salida - Cambio de dirección del (GRE) L3 + asignación del hash; esto requiere el proceso del software.
  4. Salida - Cambio de dirección del (GRE) L3 + asignación de la máscara; esto requiere el proceso del software.

Ingreso - Cambio de dirección del (GRE) L3 + asignación del hash

En el Supervisor Engine 2, cada Paquete GRE se envía al (MSFC) de la Multilayer Switch Feature Card para procesar. Puesto que la encapsulación GRE no se soporta en hardware, el MSFC debe aplicar las encabezados GRE y WCCP, que fuerza la transferencia del software para todo el tráfico.

Con el método de asignación hash-basado, el Supervisor Engine 32 y el Supervisor Engine 720 adelante el primer paquete de cada flujo en el software para establecer una entrada de tabla del Netflow. El paquete después se encapsula en el GRE (la encapsulación y la expedición del paquete inicial se hace en el software) y se remite al dispositivo WCCP.

El establecimiento de la entrada del Netflow afecta la utilización de la CPU, pero la expedición de paquete subsiguiente se hace en hardware para el Supervisor Engine 720 y el Supervisor Engine 32. Los patrones de tráfico, especialmente el número de flujos únicos, dictan cuánto se utiliza el CPU. Si los recursos del Netflow del Catalyst 6500 se consumen, después todo el tráfico se remite en el software.

Los recursos del Netflow del supervisor PFC diferencian a través de las diversas Plataformas. Actualmente, los recursos más grandes del Netflow están disponibles en el PFC-3BXL en la plataforma del Supervisor Engine 720.

Ingreso - Cambio de dirección del (GRE) L3 + asignación de la máscara

En el Supervisor Engine 2, cada Paquete GRE se envía al MSFC para procesar. Puesto que la encapsulación GRE no se soporta en hardware, el MSFC debe aplicar las encabezados GRE y WCCP, que fuerza la transferencia del software para todo el tráfico.

Con el método de asignación basado en máscaras, el Supervisor Engine 32 y el Supervisor Engine 720 adelante la inicial y los paquetes subsiguientes en hardware, porque el GRE se soporta nativo, y la asignación de la máscara utiliza el hardware TCAM ACL para remitir.

Salida - Cambio de dirección del (GRE) L3 + asignación del hash

En el Supervisor Engine 2, cada paquete se envía al MSFC para procesar. Puesto que la encapsulación GRE no se soporta en hardware, el MSFC debe aplicar las encabezados GRE y WCCP, que fuerza la transferencia del software para todo el tráfico.

Con el método de asignación hash-basado con el Supervisor Engine 32 y el Supervisor Engine 720, el Catalyst 6500 adelante el paquete inicial de cada flujo en el software para establecer la entrada de tabla del Netflow. El paquete después se encapsula en el GRE y se remite a la entidad WCCP.

El establecimiento de la entrada del Netflow afecta la utilización de la CPU, pero la expedición de paquete subsiguiente se hace en hardware. Los patrones de tráfico, especialmente el número de flujos únicos, dictan cuánto se utiliza el CPU. Si los recursos del Netflow del Catalyst 6500 se consumen, después todo el tráfico se remite en el software.

Los recursos del Netflow del supervisor PFC diferencian a través de las diversas Plataformas. Actualmente, los recursos más grandes del Netflow están disponibles en el PFC-3BXL en la plataforma del Supervisor Engine 720.

Salida - Cambio de dirección del (GRE) L3 + asignación de la máscara

En el Supervisor Engine 2, cada paquete se envía al MSFC para procesar. Puesto que la encapsulación GRE no se soporta en hardware, el MSFC debe aplicar las encabezados GRE y WCCP, que fuerza la transferencia del software para todo el tráfico.

Con el método de asignación basado en máscaras con el Supervisor Engine 32 y el Supervisor Engine 720, el primer paquete de cada flujo es conmutado por software para establecer la entrada de tabla del Netflow. Ningunos de los supervisores soportan la adyacencia de la salida ACL que programa, que fuerza este software que procesa y utiliza los recursos del Netflow (en vez del hardware ACL TCAM) para el paquete inicial en cada flujo. El paquete después se encapsula en el GRE y se remite al dispositivo WCCP.

El establecimiento de la entrada del Netflow afecta la utilización de la CPU, pero la expedición de paquete subsiguiente se hace en hardware. Los patrones de tráfico, especialmente el número de flujos únicos, dictan cuánto se utiliza el CPU. Si los recursos del Netflow del Catalyst 6500 se consumen, después todo el tráfico se remite en el software.

Los recursos del Netflow del supervisor PFC diferencian a través de las diversas Plataformas. Actualmente, los recursos más grandes del Netflow están disponibles en el PFC-3BXL en la plataforma del Supervisor Engine 720.

Método de reenvío L2

Con la expedición L2, las entidades WCCP (ACNS, WAFS, WAAS, y así sucesivamente) dentro de un grupo de servicios son parte de la misma subred y son L2 adyacente al Catalyst 6500. Esto habilita el alto rendimiento, cambio de dirección de la latencia baja del tráfico. La interfaz de ingreso (donde se configura el WCCP) y la interfaz donde se localizan los dispositivos WCCP deben estar en diversos VLA N.

Nota: Con el cambio de dirección L2, el paquete se reescribe con el conjunto del MAC de origen al router y al MAC de destino fijados al motor del caché. La única desventaja de este método de redireccionamiento es que el motor del caché debe ser L2 accesible por el Catalyst 6500 y debe residir en una diversa interfaz L3 que la interfaz configurada del ingreso WCCP.

Nota: El método de expedición al dispositivo WCCP puede no ser el mismo método que el dispositivo WCCP utiliza para enviar el tráfico de nuevo al Catalyst 6500. El WCCP se utiliza para negociar un método delantero y de vuelta que ambos dispositivos soporten. Vea el método de la vuelta WCCP.

Las opciones disponibles para el redireccionamiento de WCCP en este escenario incluyen:

  • Ingreso - Cambio de dirección L2 + asignación del hash; esto requiere el proceso del software.
  • Ingreso - El cambio de dirección L2 + la asignación de la máscara esto requiere el hardware lleno que procesa y se recomienda.
  • Salida - Cambio de dirección L2 + asignación del hash; esto requiere el proceso del software.
  • Salida - Cambio de dirección L2 + asignación de la máscara; esto requiere el proceso del software.

Ingreso - L2 + asignación del hash

Cuando está configurado en el ingreso con el L2 + la asignación del hash, tráfico WCCP envía el primer paquete en cada flujo para ser conmutados por software, que crea una entrada del Netflow en la tabla del Netflow del hardware.

Nota: La flujo-máscara del Netflow se fija para interconectar al modo flujo completo, que pudo afectar otras características del Netflow configuradas en el Switch.

Puesto que el WCCP es un mecanismo apátrida, la información no se mantiene en el software; bastante, se mantiene en hardware como las entradas en la tabla del Netflow. El tráfico subsiguiente en el flujo se remite en hardware mientras exista una entrada de tabla del Netflow.

El establecimiento de la entrada del Netflow afecta la utilización de la CPU, pero la expedición de paquete subsiguiente se hace en hardware. Los patrones de tráfico, especialmente el número de flujos únicos, dictan cuánto se utiliza el CPU. Si los recursos del Netflow del Catalyst 6500 se consumen, después todo el tráfico se remite en el software.

Los recursos del Netflow del supervisor PFC diferencian a través de las diversas Plataformas. Actualmente, los recursos más grandes del Netflow están disponibles en el PFC-3BXL en la plataforma del Supervisor Engine 720.

Ingreso - L2 + asignación de la máscara

Cuando está configurado en el ingreso, el L2 + la asignación de la máscara es el método más eficiente WCCP soportado en el Catalyst 6500. Todo el tráfico es hardware conmutado, incluyendo el paquete inicial en cada flujo. No se requiere ningún cambio de dirección del software; la inicial y la expedición de paquete subsiguiente son proporcionadas por el hardware.

Utilizan a los Recursos TCAM del hardware ACL del Catalyst 6500 para preprogramar las entradas del hardware antes de que se reciba cualquier paquete WCCP.

Para utilizar este método y utilizar el Hardware Switching lleno, la entidad WCCP debe también soportar el L2 reorienta y el método de asignación basado en máscaras. La configuración de este método se completa en la entidad WCCP, y el Catalyst 6500 negocia el mejor método durante las comunicaciones de la inicial WCCP con la entidad/el grupo WCCP.

Salida - L2 + asignación del hash

Con la salida el L2 + la asignación del hash, tráfico WCCP envía el primer paquete en cada flujo para ser conmutados por software, que crea una entrada del Netflow en la tabla del Netflow del hardware.

Nota: La flujo-máscara del Netflow se fija para interconectar al modo flujo completo, que pudo afectar otras características del Netflow configuradas en el Switch.

Además, cuando están configuradas en la dirección de salida, las operaciones de búsqueda adicionales de la Base de información de reenvío (FIB) se requieren en el primer paquete del flujo para determinar la adyacencia asociada al CE, que requiere la recirculación del paquete dentro del Catalyst 6500. Los paquetes subsiguientes son Netflow conmutado en hardware.

El establecimiento de la entrada del Netflow afecta la utilización de la CPU, pero la expedición de paquete subsiguiente se hace en hardware. Los patrones de tráfico, especialmente el número de flujos únicos, dictan cuánto se utiliza el CPU. Si los recursos del Netflow del Catalyst 6500 se consumen, después todo el tráfico se remite en el software.

Los recursos del Netflow del supervisor PFC diferencian a través de las diversas Plataformas. Actualmente, los recursos más grandes del Netflow están disponibles en el PFC-3BXL en la plataforma del Supervisor Engine 720.

Salida - L2 + asignación de la máscara

Cuando está configurado en la dirección de salida, el L2 + la asignación de la máscara conmuta el primer paquete en cada flujo en el software, apenas como L2 + caso de la asignación del hash. Los paquetes subsiguientes son Netflow conmutado en hardware.

Nota: La flujo-máscara del Netflow se fija para interconectar al modo flujo completo, que pudo afectar otras características del Netflow configuradas en el Switch.

El PFC2 y el PFC3 no soportan la adyacencia de la salida ACL que programa, que fuerza el software que procesa para el paquete inicial en cada flujo; los paquetes subsiguientes en el flujo se remiten en hardware.

El establecimiento de la entrada del Netflow afecta la utilización de la CPU, pero la expedición de paquete subsiguiente se hace en hardware. Los patrones de tráfico, especialmente el número de flujos únicos, dictan cuánto se utiliza el CPU. Si los recursos del Netflow del Catalyst 6500 se consumen, después todo el tráfico se remite en el software.

Los recursos del Netflow del supervisor PFC diferencian a través de las diversas Plataformas. Actualmente, los recursos más grandes del Netflow están disponibles en el PFC-3BXL en la plataforma del Supervisor Engine 720.

Método de la vuelta WCCP

La entidad WCCP puede mantener la petición

Cuando el WCCP se utiliza para interceptar el tráfico y la entidad WCCP realiza una operación completa en esos paquetes, los paquetes están entonces listos para ser enviado detrás al cliente del dispositivo WCCP. Este tráfico normalmente procesado, que es destinado de nuevo al cliente en la red, no requiere ninguna encapsulación especial cuando dispositivo enviado de los WCCP detrás hacia el cliente.

Porque la interceptación WCCP ha dado lugar al pedido de cliente que era mantenido con éxito (archivo del caché, secuencia partida del caché, archivo de WAAS), puede ser devuelta a la red como tráfico normal con la dirección destino en los paquetes que son el solicitante original. Este tráfico puede ser normalmente L3/switched por el Catalyst 6500 si está en el trayecto de red del dispositivo WCCP al cliente; con un dispositivo asociado L2 WCCP, el tráfico está en el trayecto de red. No hay encapsulación necesaria para devolverlo del dispositivo WCCP al Catalyst 6500 porque el destino ahora es el cliente original en vez de un servidor en Internet o el intranet. La red después dirige esto como cualquier otro flujo del tráfico IP y utiliza el hardware que reenvía en el Catalyst 6500 para volver el tráfico pedido al cliente.

La entidad WCCP no puede mantener la petición

En algunos casos donde la entidad WCCP no puede realizar la operación solicitada, el dispositivo WCCP puede necesitar enviar el tráfico de nuevo al Catalyst 6500 y preservar el destino original de los paquetes. El envío de este tráfico de la entidad WCCP sin la encapsulación puede dar lugar a los loopes del tráfico. Para ocultar un servicio fracasado intente del cliente y envíe los paquetes al destino original que se mantendrá, los paquetes debe permanecer sin cambiar, se coloque nuevamente dentro de su trayecto de reenvío original, y se remite sin la interceptación WCCP al destino original.

En el método de la vuelta WCCP, el WCCP se puede utilizar para encapsular estos paquetes, los envía de nuevo al dispositivo que los interceptó en el primer lugar, pela cualquier encapsulación, y los coloca nuevamente dentro del trayecto de reenvío del cual fueron interceptados. Estos paquetes necesitan ser enviados normalmente como si nunca fueran interceptados por el WCCP.

Los ejemplos de estos casos incluyen:

  • Oculte el tráfico sobrecargado, donde se está desviando el tráfico
  • Reglas en los dispositivos del caché que niegan la entidad WCCP de mantener el tráfico
  • Tráfico desviado que está buscando un servicio no disponible en el dispositivo

Ahora, este método de vuelta se puede hacer solamente con la encapsulación GRE y todavía no se soporta en ningún hardware del Catalyst 6500. Si una gran cantidad de tráfico se devuelve al Catalyst 6500 con este método, CPU elevada la utilización pudo ocurrir porque este tráfico se procesa en el software. En el Cisco IOS Software Release 12.1(18)SXH, hay un método de la vuelta L2 soportado por el hardware del Catalyst 6500.

El GRE vuelve

En las versiones de Cisco IOS Software anterior que 12.2(18)SXH, el único método de vuelta soportado para el Catalyst 6500 es encapsulación GRE. Además del encabezado GRE añadido al final del fichero al tráfico de retorno, una encabezado WCCP también se añade al final del fichero. Aunque el GRE se soporte nativo en el hardware del Supervisor Engine 32 y del Supervisor Engine 720, esta encabezado adicional da lugar al GRE no que es hardware ayudado. Observe que el Catalyst 6500 y el dispositivo WCCP deben soportar y negociar el método de la vuelta L2.

Ningún soporte del hardware GRE existe en el Supervisor Engine 2 para cualquier GRE, ingreso, salida, o vuelta WCCP. Para procesar este tipo de-encapsulación GRE, el Cisco IOS Software programa la recibir-adyacencia del túnel GRE WCCP en la interfaz habilitada WCCP señalar al (RP) del Route Processor, que da lugar al proceso del software del tráfico de retorno.

El uso del reorienta las listas en el Catalyst 6500 para evitar el tráfico que puede necesitar ser vuelto con el GRE es un método eficaz para reducir los requisitos de procesamiento del software del tráfico que serían devueltos de la entidad WCCP. Esto es mucho más eficaz que teniendo tráfico negado en la entidad WCCP y forzándolo para ser GRE encapsulado y devuelto al Catalyst 6500.

Recuerde que el grupo de servicios WCCP es scalable. Si el tráfico en exceso debe desviado cargar, después se devuelve este tráfico, que crea carga de la CPU en el Catalyst 6500. El escalamiento o aún el overbuilding apropiado del grupo de servicios WCCP es el único método para evitar esta situación.

Mejora de la vuelta L2

En 12.2(18)SXH, una opción permite que la entidad WCCP reescriba la dirección MAC L2 bastante que el tráfico de retorno. Esta mejora de la vuelta L2 (Id. de bug Cisco CSCuk59825) habilita el proceso del hardware del tráfico vuelto cuando el WCCP se configura para utilizar el cambio de dirección del ingreso con la asignación de la máscara.

Resumen de opciones WCCP

Cuando está implementado en el Catalyst 6500, el WCCP ofrece muchas opciones de configuración, tal y como se muestra en de esta tabla. Observe que el dispositivo WCCP negocia estas opciones y controles que las opciones sean utilizadas por el Catalyst 6500. La configuración se hace en el lado del dispositivo WCCP de la conexión WCCP.

Reoriente el métodoAsignación
Método
Ingreso
Egress
Conmutar el resultado
L2HashAccesoProceso del software
L2 (recomendado)MáscaraAccesoHardware lleno que procesa con ACL TCAM
L2HashEgressProceso del software
L2MáscaraEgressProceso del software
GREHashAccesoProceso del software
GRE (PFC3 o más nuevo)MáscaraAccesoHardware lleno que procesa con el Netflow a todo régimen
GREHashEgressProceso del software
GREMáscaraEgressProceso del software

De una perspectiva del hardware, todas las configuraciones de WCCP de la salida requieren el proceso del software y la utilización de la CPU del impacto. El proceso del software también se requiere en el ingreso cuando el método de asignación hash-basado se utiliza y da lugar al mismo impacto potencial en la utilización de la CPU.

El método recomendado de despliegue WCCP en el Catalyst 6500 es el cambio de dirección L2 con la asignación de la máscara y, cuando está disponible, la vuelta L2.

Consejo: Solamente una opción asegura el rendimiento alto, expedición basado en hardware completa: el cambio de dirección ingreso-basado L2 con la asignación de la máscara en el Supervisor Engine 2, el Supervisor Engine 32, y el Supervisor Engine 720.

Recomendaciones sobre diseño WCCP

Utilice estas recomendaciones para la configuración así que usted puede determinar el mejor método de despliegue WCCP para su situación.

Resumen

Diseñe la red tales que el ingreso WCCP se puede utilizar como método de redireccionamiento. Un buen método de diseño es tener un switchblock de almacenamiento en memoria inmediata como parte de un jerárquico, la Red de distribución L3; esto se asegura de que el tráfico mantenido WCCP se pueda identificar en algunos puertos de ingreso importantes.

  • Utilice 12.2(18)SXF7 o un más nuevo Cisco IOS Software.
  • Identifique y reoriente el tráfico en las interfaces de ingreso.
  • Utilice los dispositivos WCCP que soportan el L2 reorientan el método.
  • Utilice los dispositivos WCCP que soportan el método de asignación basado en máscaras.
  • Si es posible, utilice una lista de la reorientación en el Catalyst 6500 para el tráfico que no se puede mantener por el dispositivo WCCP.
  • Pellizque los temporizadores del Netflow con la salida o cualquier configuración hash-basada de la asignación con el Supervisor Engine 720.
  • Los dispositivos WCCP deben tener un entorno dedicado L3 y interfaz SVI/VLAN.

116134-config-wccp-6500-02.jpg116134-config-wccp-6500-03.jpg

Además, el servicio avanzado de Cisco recomienda estos aspectos del diseño:

  • En un entorno que no es L2 reorienta completamente con la asignación de la máscara, el Supervisor Engine 720 no se realiza mejor que la plataforma del Supervisor Engine 2. No actualice el hardware y cuente con el mejor rendimiento en esta situación.
  • Para grande, las implementaciones del sitio central con los requisitos de tráfico en grandes cantidades, consideran un diseño con el Routing basado en políticas (PBR) y Cisco contenta el motor modelo del control de la transferencia (CS) /Application (ACE) para la interceptación y la expedición del tráfico.
  • El WCCPv2 funciona como se esperaba bajo circunstancias perfectas. Sin embargo, en algunas circunstancias, la utilización de la CPU en el router puede alcanzar los niveles elevados que hacen el dispositivo inutilizable y que requieren la recarga:

    • El WCCPv2 baja del modo de asignación basado en máscaras acelerado por hardware L2 del ingreso en cualquier otro modo que requiera el CPU en el MSFC.
    • El WCCP se configura incorrectamente (por ejemplo, salida en vez del ingreso o del hash L2 en vez de la asignación de la máscara).
  • Cualquier despliegue del volumen alto WCCP con el Catalyst 6500 (almacenamiento en memoria inmediata, el fluir, WAAS, u otros “escenarios de la tarifa del mucho tráfico”) debe ser funcionamiento probado con el tráfico real antes de la implementación de producto completa.

Recomendaciones adicionales

Utilice una lista de la reorientación en el Switch para evitar los paquetes que se devuelven al Catalyst 6500. Si algunas reglas de los dispositivos del caché se pueden mover al Catalyst 6500 mientras que una lista de la reorientación, esto puede proporcionar un mejor rendimiento del hardware.

Los recursos del Netflow en la plataforma del Supervisor Engine 720 pueden ser agotados rápidamente si usted utiliza cualquier método con excepción de la asignación de la máscara ingress-L2. El Supervisor Engine 720 no proporciona el mejor rendimiento que el Supervisor Engine 2 con ningún otro método.

En caso de que el Supervisor Engine 720 o el Supervisor Engine 32 se deba utilizar en un diseño no óptimo, considere el uso del comando rápido de la creación software-MODE del Netflow del IP de los mls para poder acelerar el proceso del Netflow del paquete de la inicial WCCP. Esto quita las mejoras agregadas al Netflow del Supervisor Engine 32 y del Supervisor Engine 720 y proporciona el funcionamiento igual al del hardware del Netflow del Supervisor Engine 2.

La configuración para un Cisco Content Engine (CE) para la asignación de la máscara es:

  • versión 2 del wccp
  • IP address del número de lista del router del wccp
  • numéricos router-lista-numéricos del servicio del wccp máscara-asignan

Utilice estos comandos para revisar la utilización del Netflow y determinarla si el WCCP está utilizando encima de las entradas del Netflow y está utilizando el proceso del software:

  • muestre la tabla-contención del Netflow de los mls detallada
  • muestre el IP del Netflow de los mls SW-instalado
  • muestre el envejecimiento del Netflow de los mls
  • muestre a IP del Netflow de los mls la cuenta dinámica
  • muestre la cuenta del IP del Netflow de los mls
  • muestre el IP de los mls
  • muestre los contadores del Netflow del fm

Si usted experimenta los problemas de software WCCP porque se están consumiendo los recursos del Netflow, estos comandos pudieron quitar agresivamente las entradas existentes y crear el sitio para las nuevas entradas. (Esto no ayuda si hay simplemente más entradas que hay espacio del Netflow.)

  • mls que envejecen el umbral rápido 1 del tiempo 3
  • mls que envejecen de largo 64
  • mls que envejecen 32 normales
  • creación software-MODE del Netflow del IP de los mls rápida (éste inhabilita algunos cambios del Netflow del Supervisor Engine 720 que no estaban en el Supervisor Engine 2.)

Para evitar las caídas de paquetes, las entidades WCCP deben reorientar el tráfico fuera de una interfaz que no sea la interfaz que el WCCP está configurado encendido. El Catalyst 6500 WCCP cae los paquetes en esta situación cuando se cumplen todas las condiciones:

  • Los clientes y la entidad WCCP están en la misma interfaz L3.
  • La directiva del redireccionamiento de WCCP se aplica en esta interfaz.
  • Se utiliza el método de la redirección GRE.
  • Se requiere la reorientación de la fragmentación de paquetes.
  • Se utiliza el Supervisor Engine 720.

Esta situación es causada por los mecanismos de protección incorporados al Catalyst 6500; el Cisco IOS Software tiene controles que eviten que el paquete ingresar y deje la misma interfaz virtual del Cisco IOS Software donde podría potencialmente colocar y causar el comportamiento no deseado. Mueva los dispositivos WCCP a su propio entorno dedicado L3 para prevenir esto.

La limitación basada en el usuario de la tarifa (UBRL) y el WCCP no trabajan simultáneamente en una interfaz debido al flowmasks. Hay un flowmask para cada interfaz para cada característica de unidifusión. El WCCP requiere a todo régimen, y UBRL utiliza el src-solamente o el dst-solamente.

El soporte WCCP fue agregado para el Supervisor Engine 2 y la vuelta L2 en 12.2(18)SXF5. Esto no estaba en el Supervisor Engine 720 hasta 12.2(18)SXH en abril /May 2007.

Solamente el cambio de dirección WCCP L2 PFC se soporta con el Equilibrio de carga de servidores (SLB) del Cisco IOS Software; otras configuraciones de WCCP no son compatibles, y el GRE no trabaja. El comando acelerado WCCP se aplica solamente al Supervisor Engine 2/MSFC2. Su propósito es forzar al router a negociar la asignación de la máscara y el L2 reorienta, así que significa que todo el redireccionamiento de WCCP está hecho en hardware. El Supervisor Engine 32 y el Supervisor Engine 720 negocian esto sin la necesidad de este comando.

Soluciones

Nota: Use la Command Lookup Tool (clientes registrados solamente) para obtener más información sobre los comandos usados en esta sección.

ACNS

Para el cambio de dirección estándar del Almacenamiento en memoria caché transparente, recuerde que la entidad WCCP proporciona al router WCCP con los métodos aceptados y puede necesitar ser configurado para hacer tan. Para Cisco ACNS, este ejemplo de configuración pide el L2-redirect optimizado y los métodos de asignación basados en máscaras:

  1. Asegúrese que usted tenga WCCPv2 para las optimizaciones del Catalyst 6500:

    ContentEngine(config)# wccp version 2
  2. Configure una lista del router que defina el Catalyst 6500s para utilizar:

    ContentEngine(config)# wccp router-list 1 172.16.16.1
  3. Configure el servicio para utilizar los métodos de la optimización:

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

Del lado del router, el diseño del Catalyst 6500 debe asegurarse de que los dispositivos WCCP estén en una interfaz dedicada L3 que no esté en el trayecto del tráfico actual (ingreso o salida). Para el rendimiento del hardware, los flujos de tráfico deben ser entrantes capturado al Catalyst 6500, incluso si éste requiere la configuración de más interfaces que si una sola interfaz de egreso fue elegida. Un diseño ideal agregaría todo el tráfico antes de alcanzar este dispositivo, y solamente algunas interfaces requerirían la configuración del ingreso WCCP.

La configuración de WCCP en el Catalyst 6500 debe ser:

  1. WCCPv2 de la configuración:

    6500Switch# ip wccp version {1 | 2}
  2. Configure a un grupo de servicios WCCP.

    6500Switch (config)# ip wccp service [accelerated] redirect-list access-list
    Utilice el comando acelerado solamente para las Plataformas del Supervisor Engine 2 con el Cisco IOS Software 12.1E.

La lista de la reorientación se utiliza para identificar el tráfico que se debe seleccionar o no seleccionar para el cambio de dirección. Recuerde que este ACL se puede realizar en hardware, que es una manera mucho más eficiente de prevenir el cambio de dirección para el tráfico que no se puede mantener por el dispositivo WCCP. Trafique que se envía al dispositivo y no se puede mantener allí se debe volver a este Catalyst 6500 para ser puesto nuevamente dentro del trayecto del tráfico original, que requiere el proceso adicional. Las Listas de acceso WCCP son estándar o listas de acceso ampliadas.

Este ejemplo muestra que cualquier petición de 10.1.1.1 a 12.1.1.1 desvía el caché y que el resto de las peticiones están reorientadas.

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

Configure el método del ingreso WCCP en cada interfaz de ingreso que reciba el tráfico que se reorientará:

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

Esto completa la configuración en el dispositivo WCCP y el Switch, así que el cambio de dirección del tráfico debe ocurrir en este momento.

Las configuraciones de WCCP finales de los dispositivos parecen esto.

DispositivoConfiguración
Dispositivo WCCP
wccp version 2
wccp router-list 1 router-ip-addresses
wccp service router-list-num 1 l2-redirect mask assign
Router WCCP:
global
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
Router WCCP:
cada interfaz de ingreso
ip wccp redirect service in

Para marcar esta configuración, ingrese este comando:

Show ip wccp service detail

Para las opciones de configuración de WCCP adicionales, tales como dirección de grupo usando el Multicast o la Seguridad adicional WCCP, refiera a configurar caché Web los servicios usando el WCCP.

Comandos show and debug IOS WCCP

  • muestre el número de servicio del wccp del IP - proporciona la cuenta reorientada los “totales de paquetes”. Esta cuenta es el número de flujos, o las sesiones, se reorientan que.
  • muestre el detalle del número de servicio del wccp del IP - proporciona la cuenta reorientada los “paquetes”. La cuenta es el número de flujos, o las sesiones, se reorientan que.
  • muestre el detalle del caché Web del wccp del IP - proporciona una indicación de cuántos flujos, bastante que los paquetes, están utilizando el cambio de dirección L2.
  • clear ip wccp - reajusta el contador para la información reorientada los “paquetes”.
  • muestre la opinión del número de servicio del wccp del IP - visualiza los dispositivos WCCP que son parte del grupo de servicios.
  • muestre el servicio del número de servicio del wccp del IP - visualiza el hash, los puertos, y la prioridad WCCP del servicio. Golpean a servicios más prioritarios primero cuando configuran a los servicios múltiples en la interfaz.
  • los eventos wccp del IP del debug - resuelve problemas el estado del protocolo WCCP.
  • haga el debug de los paquetes del wccp del IP - revisa las comunicaciones entre el paquete WCCP que procesa las entidades.

Cuando usted utiliza el WCCP y el hardware que reenvía, algunos contadores pueden no visualizar como se esperaba:

  • Si el WCCP ACL se procesa totalmente en hardware, los contadores WCCP pueden no visualizar las cuentas de paquetes exactas.
  • Si el WCCP está utilizando la asignación y a los Recursos de hardware hash-basados del Netflow, los contadores WCCP pueden reflejar el número de flujos en vez del número de paquetes.

Comandos del Netflow

Cuando usted tiene configuraciones de WCCP que requieran el uso de los Recursos de hardware del Netflow, utilice este Multilayer Switching (MLS) y al Fabric Manager (FM) comandos así que usted puede revisar el estatus de los recursos del Netflow:

  • muestre la tabla-contención del Netflow de los mls detallada
  • muestre el IP del Netflow de los mls SW-instalado
  • muestre el envejecimiento del Netflow de los mls
  • muestre a IP del Netflow de los mls la cuenta dinámica
  • muestre la cuenta del IP del Netflow de los mls
  • muestre el IP de los mls
  • muestre los contadores del Netflow del fm

Defectos WCCP

Esta tabla del bug Cisco ID y de resoluciones soporta la recomendación general de utilizar el Cisco IOS Software Release 12.2(18)SXF7 o Posterior para el mejor soporte del WCCP.

ID de falla de funcionamiento de CiscoResuelto en la versión de Cisco IOS SoftwareDetalles
CSCsd2032712.2(18)SXF7El WCCP para el servicio 90 va hacia arriba y hacia abajo, y causa una pérdida de servicio WCCP. Este problema ocurre cuando configuran a los servicios 81, 82, y 90. Las trazas del paquete indican que el router pudo responder a los mensajes de “Here_I_Am” del caché con los mensajes del “i_see_you” que contienen un IP Address de destino incorrecto.
CSCsa7778512.2(18)SXF6Una recarga pudo ocurrir cuando usted utiliza el cambio de dirección WCCP L2 y al modo de asignación de la máscara con un estándar basado en el host ACL mientras que un WCCP reorienta el ACL.
CSCse6971312.2(18)SXF6Cuando todos los motores del caché en un grupo de servicios WCCP se pierden, el tráfico se procesa en el software en vez de conmutado en hardware.
CSCsd2887012.2(18)SXF5En un WCCP reoriente la lista ACL, los ACE que se configuran con la palabra clave del registro no se programan en la tabla TCAM.
CSCsb6102112.2(18)SXF5CPU elevada la utilización pudo ocurrir en un Supervisor Engine 720 o un Supervisor Engine 32 cuando la característica del IP spoofing se configura en un motor del caché y cuando el redireccionamiento de WCCP se configura en la dirección de salida. los paquetes del IP-spoofed del motor del caché, con un destino del cliente o del servidor, se conmutan en el software en vez del hardware.

Como solución alternativa, utilice el servicio del wccp del IP reorientan en el comando para el entrante y las interfaces de salida.
CSCsb2197212.2(18)SXF2Con el WCCP y el NDE configurados, usted puede ser que vea el tracebacks numeroso causado por los errores de alineación, y la utilización de la CPU pudo ser inaceptable alta.
CSCeh8508712.2(18)SXFCuando hay usuario configurado “deny ip any any” en el WCCP reoriente el ACL y cuando están manteniendo a muchos grupos de servicios WCCP, el tráfico asociado a algunos grupos de servicios no se reorienta al Routers CE.
CSCeh5691612.2(18)SXFCuando se habilita un servicio WCCP, cuando la asignación de la máscara se configura como el método de asignación, y cuando cinco o más cachés están en el grupo de servicios, los mensajes de protocolo enviados al caché pueden desbordar y causar la corrupción de la memoria y la recarga.
CSCsb1874012.2(18)SXF y SXE6En el modo de reenvío GRE-basado, el WCCP utiliza innecesariamente un caché del software que aumente la utilización de la CPU MSFC.
CSCsb2677312.2(18)SXFUn ACL entrante pudo hacer el redireccionamiento de WCCP fallar con la pérdida de todo el tráfico redirigido.
CSCsa9083012.2(18)SXE2El tráfico ingreso-reorientado WCCP utiliza la tabla del Netflow para el Hardware Switching cuando el motor del caché se configura para la expedición GRE con el modo de asignación de la máscara. Cuando la tabla del Netflow es llena, el cambio de dirección del ingreso WCCP falla.
CSCec5542912.2(18)SXELa lista del grupo de servicios WCCP es analizada en la orden en la cual crean a los grupos de servicios, bastante que por la prioridad. Si definen a los servicios dinámicos múltiples WCCP, trafique para que hace juego el Criterio de selección a más de un grupo de servicios no se reorienta al grupo de servicios con la prioridad más alta.
CSCuk5087812.2(18)SXE

En una versión donde se resuelve el Id. de bug Cisco CSCec55429, después de vario WCC “caché perdió” y los eventos encontrados “caché” han ocurrido para todos los cachés en un grupo de servicios, estos eventos pueden ocurrir:

  • Los accesos de memoria espurios pudieron ocurrir.
  • La adición y la cancelacíon de los servicios WCCP pudieron fallar.
  • El comando show ip wccp visualiza el servicio WCCP, pero la salida del comando del service_number del wccp del IP de la demostración no muestra el servicio WCCP.
CSCsa6761112.2(18)SXELos paquetes entrantes del Multiprotocol Label Switching (MPLS) que salen en una interfaz NON-MPLS (etiqueta al trayecto IP) en la cual se configure una función de resultados (por ejemplo, la salida ACL o la salida WCCP) no pudieron tener las funciones de resultados aplicadas. Este problema ocurre porque se desvían las operaciones de búsqueda del ACL de salida.
CSCeh1329212.2(18)SXD4La configuración del WCCPv2 en un Supervisor Engine 720 causa CPU elevada la utilización.
CSCeb2894112.2(18)SXD1El Network Address Translation (NAT) no trabaja con el WCCP configurado.
CSCed9229012.2(17d)SXB2los paquetes WCCP-reorientados que no tienen ninguna entrada de caché del Address Resolution Protocol (ARP) del Next-Hop son proceso conmutado para generar un pedido ARP. Debido al redireccionamiento de WCCP, sin embargo, no se envía ningún pedido ARP, memoria caché ARP nunca se puebla para el salto siguiente, y los paquetes WCCP-reorientados subsiguientes continúan siendo proceso conmutado. 
CSCuk5982512.2(17d)SXF5 -Sup2 Whitney1.0 para el Sup720Este soporte del hardware agregado versión de Cisco IOS Software para el tráfico de retorno L2. El request for comment (RFC) WCCP especifica la vuelta L2 como capacidad opcional para la negociación entre el router y el caché. Hasta ahora, el WCCP en el Cisco IOS Software no ha permitido la negociación de esta capacidad porque el soporte del hardware necesario está ausente. Que el soporte ahora es disponible, así que la negociación de la vuelta L2 en el intercambio de protocolos WCCP entre el router y caché puede ser habilitado.


Document ID: 116134