Guide de configuration de WCCP sur les plates-formes Catalyst 6500 avec utilisation élevée du CPU

Introduction

Ce document décrit comment utiliser le protocole WCCP (Web Cache Communication Protocol) sur la plate-forme de la gamme Cisco Catalyst 6500.

WCCP a été initialement conçu comme une méthode d'interception du trafic Web (HTTP) et de le transférer à un périphérique de cache local, où il peut être desservi à un client à partir d'un emplacement local et conserver une bande passante WAN coûteuse.

Du point de vue de l'utilisateur du réseau, WCCP est transparent car il est utilisé au niveau du réseau, sans configuration particulière de la part de l'utilisateur, afin d'identifier et de rediriger le trafic Web qui traverse un périphérique de couche 3 (L3) vers un périphérique de cache local. Bien que WCCP ait été conçu à l'origine pour le trafic Web, la méthode transparente de redirection est devenue un mécanisme très utile pour résoudre d'autres problèmes avec du contenu de volume élevé sur des liaisons de faible volume. Pour cette raison, la prise en charge de protocoles supplémentaires a été ajoutée aux versions WCCP ultérieures. Ces technologies supplémentaires incluent des protocoles tels que HTTP, HTTPS, FTP, la diffusion vidéo en continu et les technologies de mise en cache de fichiers, telles que le Common Internet File System (CIFS). Ces technologies prennent en charge les nouvelles solutions et plates-formes Cisco, telles que les services de fichiers étendus (WAFS), les services d'applications étendus (WAAS), les réseaux orientés application (AON) et les fonctionnalités améliorées du logiciel de mise en réseau d'applications et de contenu (ACNS).

L'adoption du protocole WCCP augmente à mesure que les entreprises mettent en oeuvre les derniers outils de productivité, tels que les communications vidéo et la formation, ainsi que la vidéo en direct et à la demande. Les efforts de contrôle des coûts, tels que les data centers consolidés, créent la nécessité pour le WCCP de prendre en charge des services à bande passante supplémentaire extrêmement élevée.

En raison de l'importance de WCCP avec les réseaux riches en contenu actuels, certaines plates-formes, telles que Catalyst 6500, ont mis en oeuvre des performances assistées par matériel avec WCCP afin de réduire la charge CPU requise pour le protocole. Ce document décrit comment déployer WCCP sur le Catalyst 6500 afin d'optimiser l'utilisation du matériel et de réduire la charge CPU.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• WCCP
• Commutateurs de la gamme Cisco Catalyst 6500
• Logiciel Cisco IOSMD

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Commutateurs de la gamme Cisco Catalyst 6500
• Logiciel Cisco IOS Version 12.1(50)SY ou ultérieure avec Supervisor Engine 2T (carte de fonction de stratégie 4)
• Logiciel Cisco IOS Version 12.2(18)SXD1 ou ultérieure avec Supervisor Engine 720 (carte de fonction de stratégie 3)

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Présentation des fonctions WCCP

La fonctionnalité généralement appelée WCCP implique en fait trois composants :

1. Fonctionnalité mise en oeuvre uniquement sur le routeur ou le commutateur
2. Fonctionnalité implémentée uniquement au niveau de l'entité de traitement du trafic, telle qu'un cache Web
3. WCCP mis en oeuvre des deux côtés

Ce document examine ces trois caractéristiques opérationnelles WCCP :

1. La méthode d'affectation détermine le trafic WCCP et le périphérique WCCP choisi pour la destination du trafic.Le protocole WCCP prend en charge plusieurs périphériques regroupés.
2. La méthode de redirection transfère le flux de trafic vers l'appliance WCCP lorsqu'il est nécessaire de changer du chemin réseau normal traversé par le trafic.
3. La méthode de retour détermine comment le trafic est renvoyé au routeur à partir de l'appliance WCCP si le trafic n'a pas pu être traité. Dans les cas où l'appliance WCCP traite la demande, les paquets sont renvoyés directement au demandeur.

WCCP et Catalyst 6500

Les moteurs de supervision Catalyst 6500 Supervisor Engine 2, Supervisor Engine 32 et Supervisor Engine 720 prennent en charge les fonctionnalités et méthodes WCCP suivantes :

• WCCP version 2 (WCCPv2)
• Méthode d'affectation basée sur le hachage
• Méthode d'affectation basée sur des masques (accélération matérielle)
• Méthode de redirection GRE (Generic Routing Encapsulation) de couche 3 (accélération matérielle sur Supervisor Engine 32 et Supervisor Engine 720)
• Méthode de redirection de couche 2 (L2) (accélération matérielle sur Supervisor Engine 2, Supervisor Engine 32 et Supervisor Engine 720)
• Méthode de retour GRE
• Méthode de retour L2 avec le logiciel Cisco IOS Version 12.2SXH (accélération matérielle sur Supervisor Engine 2, Supervisor Engine 32 et Supervisor Engine 720)

Pour plus d'informations sur ces fonctionnalités, reportez-vous à Configuration de WCCP dans le Guide de configuration du logiciel Cisco IOS de la gamme Cisco 6500, 12.2SX.

Méthode d'affectation WCCP

L'affectation WCCP détermine le trafic redirigé par le protocole WCCP et l'entité WCCP recevant le trafic redirigé.

Lorsque WCCP est configuré sur une interface d'un routeur et sur une entité WCCP, le périphérique de redirection (le Catalyst 6500) doit savoir quel trafic doit être redirigé et où le trafic doit être envoyé. Les entités WCCP d'un cluster de groupe de services communiquent toutes via le protocole WCCP avec le Catalyst 6500 ; cependant, un appareil WCCP est sélectionné pour représenter le cluster afin de contrôler le fonctionnement du cluster (par la méthode d'affectation, la méthode de redirection, etc.). L'appliance et le routeur WCCP peuvent négocier la méthode de distribution des paquets entre les caches Web d'un groupe de services. Un groupe de services est défini comme une relation de plusieurs à plusieurs entre 32 routeurs maximum et 32 entités WCCP. La négociation se fait par groupe de services ; ainsi, les caches web qui participent à plusieurs groupes de services peuvent négocier une méthode d'affectation différente pour chaque groupe de services. Les services WCCP actuellement disponibles sont les suivants :

* Les services configurables par l'utilisateur sont implémentés dans le Catalyst 6500 avec une commande de niveau interface appliquée à une direction entrante ou sortante. Les implications du choix du trafic entrant ou sortant sont abordées plus loin, mais le trafic entrant est la méthode préférée car une liste de redirection peut être couplée à WCCP pour des performances matérielles maximales.

Une fois configuré pour WCCP, un routeur annonce les méthodes d'affectation prises en charge pour un groupe de services dans les messages de communication WCCP. L'absence d'un tel message implique que le Catalyst 6500 ne prend en charge que la méthode d'affectation basée sur le hachage par défaut.

Une fois la négociation entre le Catalyst 6500 et l'appliance WCCP terminée, l'entité désignée WCCP, via WCCP, informe le Catalyst 6500 du trafic à rediriger et des entités WCCP auxquelles le trafic est affecté. Par exemple, l'entité WCCP peut informer Catalyst 6500 de rediriger tout le trafic Web d'un sous-réseau particulier vers les moteurs de cache 1 à 4 du groupe de services lorsqu'il y a plus de quatre périphériques WCCP disponibles.

Deux méthodes d'affectation sont disponibles pour WCCP :

1. L'affectation basée sur le hachage (par défaut) utilise un algorithme de hachage basé sur le logiciel ainsi que des directives de l'appliance WCCP désignée afin de déterminer quel appareil WCCP reçoit du trafic. Dans une plate-forme Supervisor Engine 32 ou Supervisor Engine 720, les ressources matérielles NetFlow sont utilisées afin d'appliquer un certain niveau d'assistance matérielle.
2. L'affectation basée sur des masques utilise les fonctionnalités matérielles du Catalyst 6500, en particulier la mémoire TCAM (ternary content Addressable Memory) de la liste de contrôle d'accès, afin d'affecter le trafic aux entités WCCP. Il s'agit de la méthode préférée.

Tous les périphériques d'un groupe de services WCCP doivent utiliser la même méthode d'affectation. Les méthodes d'affectation sont configurées sur l'entité WCCP et apprises par Catalyst 6500. Référez-vous à Recommandations de conception WCCP pour plus de détails.

Détail de la méthode d'affectation basée sur le hachage

Le mécanisme d'affectation basé sur le hachage repose sur un algorithme exécuté dans le logiciel. Afin de tirer parti de l'algorithme de hachage, le premier paquet d'un flux particulier est envoyé du chemin matériel au chemin logiciel où le hachage est effectué.

Le logiciel effectue un hachage XOR de différents composants du flux et fournit un hachage qui fractionne les flux de trafic vers les différentes entités WCCP. Le mécanisme de hachage détermine comment le trafic est distribué entre les entités WCCP disponibles.

Le résultat du hachage est programmé dans la table NetFlow matérielle, où les paquets suivants dans ce flux sont transférés. Quels que soient les champs disponibles pour le hachage par WCCP, le tuple complet est utilisé. Cela signifie que NetFlow est mis en mode d'interface et de flux total lorsque WCCP est activé. Cela a des implications sur d'autres fonctionnalités qui peuvent nécessiter des ressources NetFlow. Voir la section WCCP Defects pour plus de détails.

Une question courante à propos de WCCP sur le Catalyst 6500 est : « Pourquoi l'utilisation du CPU augmente-t-elle lorsque j'active WCCP ? » Lorsque des affectations basées sur le hachage sont utilisées, le traitement logiciel du paquet initial dans chaque flux impose une charge au processeur et est le plus souvent la cause d'une utilisation accrue. Avec le matériel de transfert PFC3 (Policy Feature Card 3) actuellement disponible, si WCCP est configuré comme fonctionnalité de sortie ou si une affectation basée sur le hachage est en cours d'utilisation (entrée ou sortie), un certain niveau de traitement logiciel est toujours requis.

L'utilisation de la méthode d'affectation basée sur le hachage affecte ces fonctionnalités :

• Table NetFlow - Le nombre d'entrées prises en charge par la carte PFC est limité et le masque de flux passe à l'interface full-flow pour l'ensemble de la table NetFlow.
• Utilisation du CPU - Il y a une augmentation de l'utilisation du CPU car le premier paquet de chaque flux est commuté par logiciel.
• Performances - Le débit auquel le trafic est envoyé au processeur pour recherche est limité de sorte que le processeur soit protégé.
• Fonctionnalités NetFlow - D'autres fonctionnalités qui utilisent des ressources NetFlow peuvent être affectées si les ressources NetFlow sont utilisées par WCCP.

Les limitations et les implications causées par l'obligation d'affectation basée sur le hachage pour le traitement logiciel sont applicables au trafic d'entrée et de sortie. L'impact sur le processeur peut être exacerbé si le réseau connaît des modèles de trafic atypiques, tels qu'une attaque par déni de service (DoS). En cas d’attaque ou de propagation de vers, chaque paquet envoyé par un hôte est envoyé à une nouvelle destination ou à un nouveau port, ce qui entraîne le traitement de chaque paquet dans le logiciel. Puisque le trafic redirigé WCCP est explicitement envoyé au processeur pour le traitement du premier paquet, il existe des méthodes de protection limitées. L'utilisation des entrées de liste de contrôle d'accès 'deny' sur l'interface peut limiter ce qui est envoyé au processeur ; cependant, il n'y a pas de limite de débit ou d'autres protections contre ce type d'attaques.

Détail de la méthode d'affectation basée sur les masques

L'affectation basée sur les masques est traitée différemment selon qu'elle est configurée en entrée ou en sortie.

Avec l'attribution basée sur un masque d'entrée, le masque est programmé dans la TCAM de la liste de contrôle d'accès avant le transfert de paquets, de sorte que la table NetFlow et le traitement logiciel ne sont pas nécessaires. L'entité WCCP choisit un certain nombre de compartiments de hachage et attribue un masque d'adresse et une appliance WCCP à chaque compartiment. Une fois les affectations terminées, le superviseur programme une entrée TCAM et une contiguïté matérielle pour chaque compartiment et redirige les paquets qui correspondent au masque d'adresse vers l'appliance WCCP associée au moyen d'une réécriture L2.

Si WCCP est configuré comme fonction d'entrée, il peut utiliser une entrée de contiguïté de redirection de liste de contrôle d'accès dans la table de liste de contrôle d'accès matérielle. Une fois que WCCP correspond à l'entrée, il utilise une contiguïté appropriée afin d'effectuer une réécriture de couche 2 ou une encapsulation GRE. Ainsi, lorsque l'affectation de masque est utilisée en entrée, la réécriture de couche 2 (Supervisor Engine 2, Supervisor Engine 32 et Supervisor Engine 720) et l'encapsulation GRE (Supervisor Engine 32 et Supervisor Engine 720 uniquement) sont effectuées dans le matériel.

Si WCCP est configuré comme fonctionnalité de sortie, les contiguïtés de redirection d'ACL ne sont pas prises en charge dans le matériel, car les paquets du flux ont déjà été routés par le système. Le premier paquet d'un flux est envoyé au logiciel pour traitement. Une fois que la contiguïté de redirection appropriée est déterminée, elle est programmée dans le matériel NetFlow (au lieu de la TCAM ACL), où l'entrée pointe vers une contiguïté qui effectue une réécriture de couche 2 ou une encapsulation GRE. Les paquets suivants du flux sont redirigés dans le matériel par le matériel NetFlow.

Note: Si WCCP est configuré comme fonctionnalité de sortie, l'attribution de masque nécessite un traitement logiciel, ce qui exclut tout avantage de la méthode d'affectation basée sur le masque.

Parmi les deux options basées sur le masque, seule l'affectation basée sur le masque d'entrée permet le transfert complet basé sur le matériel pour les paquets initiaux et suivants. Toute autre option, telle que l'utilisation d'une affectation basée sur le hachage ou le traitement de sortie, entraîne la commutation logicielle du paquet initial et le transfert matériel commuté NetFlow des paquets suivants.

Méthode de redirection WCCP

L'entité WCCP, et non le Catalyst 6500, dicte les tables de hachage et les jeux de masque/valeur au Catalyst 6500, de sorte que la configuration de la méthode de redirection est effectuée sur cet appareil, et non sur le commutateur Catalyst 6500. Le Catalyst 6500 détermine la meilleure méthode de redirection disponible, en fonction des communications WCCP avec l'entité/le groupe WCCP. Cette négociation détermine la manière dont le trafic redirigé est transféré à l'appliance. Il existe deux options de redirection : L3 (GRE) et L2 (réécritures d'adresse MAC).

Avec WCCPv1, la seule option est la redirection de couche 3, également appelée encapsulation GRE. Avec la redirection de couche 3, chaque paquet redirigé WCCP est encapsulé dans un en-tête GRE marqué avec un type de protocole 0x883E suivi d'un en-tête de redirection WCCP de quatre octets, qui est ensuite envoyé à l'appliance WCCP (tel qu'un moteur de cache).

Avec l'introduction de WCCPv2, la redirection de couche 2, également appelée redirection WCCP accélérée, a été ajoutée afin de tirer parti des plates-formes de commutation matérielle telles que Catalyst 6500. Lorsque WCCP utilise la redirection de couche 2, l'appliance WCCP et le Catalyst 6500 doivent être contigus à la couche 2 (dans le même VLAN de couche 2). Le trafic de couche 2 redirigé n'utilise pas l'encapsulation GRE ; au lieu de cela, l'adresse de destination MAC est réécrite par le Catalyst 6500 vers celle de l'entité WCCP connectée à la couche 2 et transmise via une commutation matérielle normale.

Note: La méthode de transfert vers le périphérique WCCP peut ne pas être la même que celle utilisée par le périphérique WCCP pour renvoyer le trafic vers le Catalyst 6500. WCCP est utilisé afin de négocier une méthode de transfert et de retour prise en charge par les deux périphériques. Voir Méthode de retour WCCP.

Méthode de transfert de couche 3 (GRE)

Le fonctionnement WCCP de couche 3 implique l'utilisation de GRE comme méthode d'encapsulation. Les paquets redirigés sont encapsulés dans un en-tête GRE avec un type de protocole 0x883e, ainsi qu'un en-tête de redirection WCCP de 4 octets qui inclut un ID de service et un compartiment de hachage correspondant (WCCPv2 uniquement). L'utilisation de GRE permet de séparer le client WCCP du Catalyst 6500 par plusieurs sauts de couche 3 (routés).

Dans ce scénario, les options disponibles pour la redirection WCCP sont les suivantes :

1. Entrée - Redirection L3 (GRE) + affectation de hachage ; cela nécessite un traitement logiciel.
2. Entrée - Redirection L3 (GRE) + affectation de masque ; cela nécessite un traitement matériel complet et n'est disponible que sur le Supervisor Engine 32 ou le Supervisor Engine 720.
3. Sortie - Redirection L3 (GRE) + affectation de hachage ; cela nécessite un traitement logiciel.
4. Sortie - Redirection L3 (GRE) + affectation de masque ; cela nécessite un traitement logiciel.

Entrée - Redirection L3 (GRE) + affectation de hachage

Sur le Supervisor Engine 2, chaque paquet GRE est envoyé à la carte MSFC (Multilayer Switch Feature Card) pour traitement. Puisque l'encapsulation GRE n'est pas prise en charge dans le matériel, la carte MSFC doit appliquer les en-têtes GRE et WCCP, ce qui force la commutation logicielle pour tout le trafic.

Avec la méthode d'affectation basée sur le hachage, Supervisor Engine 32 et Supervisor Engine 720 transmettent le premier paquet de chaque flux du logiciel de sorte qu'une entrée de table NetFlow soit établie. Le paquet est ensuite encapsulé dans GRE (l'encapsulation et le transfert du paquet initial sont effectués dans le logiciel) et transmis à l'appliance WCCP.

L'établissement de l'entrée NetFlow affecte l'utilisation du CPU, mais le transfert de paquets suivant est effectué dans le matériel pour Supervisor Engine 720 et Supervisor Engine 32. Les modèles de trafic, en particulier le nombre de flux uniques, déterminent la quantité d'utilisation du processeur. Si les ressources NetFlow du Catalyst 6500 sont utilisées, tout le trafic est transféré dans le logiciel.

Les ressources NetFlow de la carte PFC du superviseur diffèrent selon les plates-formes. Actuellement, les ressources NetFlow les plus importantes sont disponibles sur la carte PFC-3BXL sur la plate-forme Supervisor Engine 720.

Entrée - Redirection L3 (GRE) + affectation de masque

Sur le Supervisor Engine 2, chaque paquet GRE est envoyé au MSFC pour traitement. Puisque l'encapsulation GRE n'est pas prise en charge dans le matériel, la carte MSFC doit appliquer les en-têtes GRE et WCCP, ce qui force la commutation logicielle pour tout le trafic.

Avec la méthode d'affectation basée sur un masque, Supervisor Engine 32 et Supervisor Engine 720 transmettent les paquets initiaux et suivants dans le matériel, car GRE est pris en charge nativement, et l'affectation de masque utilise le matériel TCAM ACL pour le transfert.

Sortie - Redirection L3 (GRE) + affectation de hachage

Sur le Supervisor Engine 2, chaque paquet est envoyé à la carte MSFC pour traitement. Puisque l'encapsulation GRE n'est pas prise en charge dans le matériel, la carte MSFC doit appliquer les en-têtes GRE et WCCP, ce qui force la commutation logicielle pour tout le trafic.

Avec la méthode d'affectation basée sur le hachage avec Supervisor Engine 32 et Supervisor Engine 720, le Catalyst 6500 transfère le paquet initial de chaque flux du logiciel afin que l'entrée de la table NetFlow soit établie. Le paquet est ensuite encapsulé dans GRE et transféré à l'entité WCCP.

L'établissement de l'entrée NetFlow a un impact sur l'utilisation du CPU, mais le transfert de paquets suivant est effectué dans le matériel. Les modèles de trafic, en particulier le nombre de flux uniques, déterminent la quantité d'utilisation du processeur. Si les ressources NetFlow du Catalyst 6500 sont utilisées, tout le trafic est transféré dans le logiciel.

Les ressources NetFlow de la carte PFC du superviseur diffèrent selon les différentes plates-formes. Actuellement, les ressources NetFlow les plus importantes sont disponibles sur la carte PFC-3BXL sur la plate-forme Supervisor Engine 720.

Sortie - Redirection L3 (GRE) + affectation de masque

Sur le Supervisor Engine 2, chaque paquet est envoyé à la carte MSFC pour traitement. Puisque l'encapsulation GRE n'est pas prise en charge dans le matériel, la carte MSFC doit appliquer les en-têtes GRE et WCCP, ce qui force la commutation logicielle pour tout le trafic.

Avec la méthode d'affectation basée sur un masque avec Supervisor Engine 32 et Supervisor Engine 720, le premier paquet de chaque flux est commuté par logiciel afin que l'entrée de la table NetFlow soit établie. Aucun des superviseurs ne prend en charge la programmation de contiguïté des listes de contrôle d'accès de sortie, qui force ce traitement logiciel et utilise des ressources NetFlow (au lieu de TCAM des listes de contrôle d'accès matérielles) pour le paquet initial dans chaque flux. Le paquet est ensuite encapsulé dans GRE et transféré à l'appliance WCCP.

L'établissement de l'entrée NetFlow a un impact sur l'utilisation du CPU, mais le transfert de paquets suivant est effectué dans le matériel. Les modèles de trafic, en particulier le nombre de flux uniques, déterminent la quantité d'utilisation du processeur. Si les ressources NetFlow du Catalyst 6500 sont utilisées, tout le trafic est transféré dans le logiciel.

Les ressources NetFlow de la carte PFC du superviseur diffèrent selon les différentes plates-formes. Actuellement, les ressources NetFlow les plus importantes sont disponibles sur la carte PFC-3BXL sur la plate-forme Supervisor Engine 720.

Méthode de transfert L2

Avec le transfert L2, les entités WCCP (ACNS, WAFS, WAAS, etc.) d'un groupe de services font partie du même sous-réseau et sont L2 adjacentes au Catalyst 6500. Cela permet une redirection du trafic à haut débit et à faible latence. L'interface d'entrée (où WCCP est configuré) et l'interface où se trouvent les appliances WCCP doivent se trouver sur différents VLAN.

Note: Avec la redirection L2, le paquet est réécrit avec l'adresse MAC source définie sur le routeur et l'adresse MAC de destination définie sur le moteur de cache. Le seul inconvénient de cette méthode de redirection est que le moteur de cache doit être accessible par L2 par le Catalyst 6500 et doit résider sur une interface L3 différente de l'interface WCCP d'entrée configurée.

Note: La méthode de transfert vers le périphérique WCCP peut ne pas être la même que celle utilisée par le périphérique WCCP pour renvoyer le trafic vers le Catalyst 6500. WCCP est utilisé afin de négocier une méthode de transfert et de retour prise en charge par les deux périphériques. Voir Méthode de retour WCCP.

Les options disponibles pour la redirection WCCP dans ce scénario incluent :

• Entrée - Redirection L2 + affectation de hachage ; cela nécessite un traitement logiciel.
• Entrée - Redirection de couche 2 + affectation de masque qui nécessite un traitement matériel complet et est recommandé.
• Sortie - Redirection L2 + affectation de hachage ; cela nécessite un traitement logiciel.
• Sortie - Redirection L2 + affectation de masque ; cela nécessite un traitement logiciel.

Entrée - L2 + Hachage

Lorsqu'il est configuré en entrée avec l'affectation de couche 2 + hachage, le trafic WCCP envoie le premier paquet de chaque flux à commuter par logiciel, ce qui crée une entrée NetFlow dans la table NetFlow matérielle.

Note: Le masque de flux NetFlow est défini sur le mode de flux complet de l'interface, ce qui peut avoir un impact sur d'autres fonctions NetFlow configurées sur le commutateur.

Étant donné que le WCCP est un mécanisme sans état, les informations ne sont pas conservées dans le logiciel ; au lieu de cela, il est maintenu dans le matériel en tant qu'entrées dans la table NetFlow. Le trafic ultérieur dans le flux est transféré dans le matériel tant qu'une entrée de table NetFlow existe.

L'établissement de l'entrée NetFlow a un impact sur l'utilisation du CPU, mais le transfert de paquets suivant est effectué dans le matériel. Les modèles de trafic, en particulier le nombre de flux uniques, déterminent la quantité d'utilisation du processeur. Si les ressources NetFlow du Catalyst 6500 sont utilisées, tout le trafic est transféré dans le logiciel.

Les ressources NetFlow de la carte PFC du superviseur diffèrent selon les différentes plates-formes. Actuellement, les ressources NetFlow les plus importantes sont disponibles sur la carte PFC-3BXL sur la plate-forme Supervisor Engine 720.

Entrée - L2 + affectation de masque

Lorsqu'elle est configurée en entrée, l'affectation de couche 2 + masque est la méthode WCCP la plus efficace prise en charge sur le Catalyst 6500. Tout le trafic est commuté au niveau matériel, y compris le paquet initial dans chaque flux. Aucune redirection logicielle n'est requise ; le transfert de paquets initial et ultérieur est fourni par le matériel.

Les ressources TCAM de la liste de contrôle d'accès matérielle du Catalyst 6500 sont utilisées afin de préprogrammer les entrées matérielles avant la réception de paquets WCCP.

Pour utiliser cette méthode et utiliser la commutation matérielle complète, l'entité WCCP doit également prendre en charge la redirection L2 et la méthode d'affectation basée sur le masque. La configuration de cette méthode est terminée sur l'entité WCCP et Catalyst 6500 négocie la meilleure méthode lors des communications initiales WCCP avec l'entité/le groupe WCCP.

Sortie - L2 + Hachage

Avec l'affectation de hachage de couche 2 de sortie, le trafic WCCP envoie le premier paquet de chaque flux à commuter par logiciel, ce qui crée une entrée NetFlow dans la table NetFlow matérielle.

Note: Le masque de flux NetFlow est défini sur le mode de flux complet de l'interface, ce qui peut avoir un impact sur d'autres fonctions NetFlow configurées sur le commutateur.

En outre, lorsqu'elle est configurée dans la direction de sortie, une recherche FIB (Transmission Information Base) supplémentaire est requise sur le premier paquet du flux afin de déterminer la contiguïté associée au CE, qui nécessite une recirculation des paquets dans le Catalyst 6500. Les paquets suivants sont commutés NetFlow dans le matériel.

L'établissement de l'entrée NetFlow a un impact sur l'utilisation du CPU, mais le transfert de paquets suivant est effectué dans le matériel. Les modèles de trafic, en particulier le nombre de flux uniques, déterminent la quantité d'utilisation du processeur. Si les ressources NetFlow du Catalyst 6500 sont utilisées, tout le trafic est transféré dans le logiciel.

Les ressources NetFlow de la carte PFC du superviseur diffèrent selon les différentes plates-formes. Actuellement, les ressources NetFlow les plus importantes sont disponibles sur la carte PFC-3BXL sur la plate-forme Supervisor Engine 720.

Sortie - L2 + affectation de masque

Lorsqu’elle est configurée dans la direction de sortie, l’affectation de couche 2 + masque commute le premier paquet dans chaque flux du logiciel, tout comme le cas de l’affectation de couche 2 + hachage. Les paquets suivants sont commutés NetFlow dans le matériel.

Note: Le masque de flux NetFlow est défini sur le mode de flux complet de l'interface, ce qui peut avoir un impact sur d'autres fonctions NetFlow configurées sur le commutateur.

Les cartes PFC2 et PFC3 ne prennent pas en charge la programmation de contiguïté des listes de contrôle d'accès de sortie, ce qui force le traitement logiciel du paquet initial dans chaque flux ; les paquets suivants dans le flux sont transférés dans le matériel.

L'établissement de l'entrée NetFlow a un impact sur l'utilisation du CPU, mais le transfert de paquets suivant est effectué dans le matériel. Les modèles de trafic, en particulier le nombre de flux uniques, déterminent la quantité d'utilisation du processeur. Si les ressources NetFlow du Catalyst 6500 sont utilisées, tout le trafic est transféré dans le logiciel.

Les ressources NetFlow de la carte PFC du superviseur diffèrent selon les différentes plates-formes. Actuellement, les ressources NetFlow les plus importantes sont disponibles sur la carte PFC-3BXL sur la plate-forme Supervisor Engine 720.

Méthode de retour WCCP

L'entité WCCP peut traiter la demande

Lorsque WCCP est utilisé pour intercepter le trafic et que l'entité WCCP effectue une opération complète sur ces paquets, les paquets sont alors prêts à être renvoyés au client à partir du périphérique WCCP. Ce trafic normalement traité, qui est destiné au client sur le réseau, ne nécessite aucune encapsulation spéciale lorsqu'il est renvoyé du périphérique WCCP vers le client.

Comme l'interception WCCP a entraîné le bon traitement de la demande du client (fichier du cache, flux fractionné du cache, fichier du WAAS), elle peut être renvoyée au réseau en tant que trafic normal avec l'adresse de destination dans les paquets en tant que demandeur initial. Ce trafic peut normalement être de couche 3/commuté par le Catalyst 6500 s'il se trouve sur le chemin réseau du périphérique WCCP au client ; avec un appareil WCCP connecté à L2, le trafic se trouve sur le chemin réseau. Aucune encapsulation n'est nécessaire pour le renvoyer du périphérique WCCP vers le Catalyst 6500, car la destination est désormais le client d'origine au lieu d'un serveur sur Internet ou intranet. Le réseau gère ensuite ce trafic comme tout autre flux de trafic IP et utilise le transfert matériel dans le Catalyst 6500 afin de renvoyer le trafic demandé au client.

L'entité WCCP ne peut pas traiter la demande

Dans certains cas où l'entité WCCP ne peut pas effectuer l'opération demandée, l'appliance WCCP peut devoir renvoyer le trafic au Catalyst 6500 et conserver la destination d'origine des paquets. Le transfert de ce trafic depuis l’entité WCCP sans encapsulation peut entraîner des boucles de trafic. Afin de masquer une tentative de service infructueuse du client et d'envoyer les paquets à la destination d'origine pour être traités, les paquets doivent rester inchangés, être placés de nouveau dans leur chemin de transfert d'origine, et transférés sans interception WCCP vers la destination d'origine.

Dans la méthode de retour WCCP, WCCP peut être utilisé pour encapsuler ces paquets, les renvoyer au périphérique qui les a interceptés en premier lieu, supprimer toute encapsulation et les remettre dans le chemin de transmission à partir duquel ils ont été interceptés. Ces paquets doivent être envoyés normalement comme s'ils n'avaient jamais été interceptés par WCCP.

Voici quelques exemples de ces cas :

• Trafic surchargé dans le cache, où le trafic est contourné
• Règles sur les périphériques de cache qui empêchent l'entité WCCP de traiter le trafic
• Trafic ignoré qui recherche un service non disponible sur le périphérique

Pour le moment, cette méthode de retour ne peut être effectuée qu'avec l'encapsulation GRE et n'est pas encore prise en charge dans aucun matériel Catalyst 6500. Si de grandes quantités de trafic sont renvoyées au Catalyst 6500 avec cette méthode, une utilisation élevée du CPU peut se produire parce que ce trafic est traité dans le logiciel. Dans le logiciel Cisco IOS Version 12.1(18)SXH, il existe une méthode de retour L2 prise en charge par le matériel Catalyst 6500.

Retour GRE

Dans les versions du logiciel Cisco IOS antérieures à 12.2(18)SXH, la seule méthode de retour prise en charge pour le Catalyst 6500 est l'encapsulation GRE. Outre l'en-tête GRE ajouté au trafic de retour, un en-tête WCCP est également ajouté. Bien que GRE soit pris en charge en mode natif dans le matériel Supervisor Engine 32 et Supervisor Engine 720, cet en-tête supplémentaire fait que le GRE n'est pas pris en charge par le matériel. Notez que le Catalyst 6500 et le WCCP doivent tous deux prendre en charge et négocier la méthode de retour L2.

Il n'existe aucune prise en charge matérielle GRE dans le Supervisor Engine 2 pour tout retour GRE, entrée, sortie ou WCCP. Afin de traiter ce type de désencapsulation GRE, le logiciel Cisco IOS programme la contiguïté de réception du tunnel WCCP GRE sur l'interface WCCP activée pour pointer vers le processeur de routage (RP), ce qui entraîne le traitement logiciel du trafic de retour.

L'utilisation de listes de redirection au niveau du Catalyst 6500 afin d'éviter le trafic qui pourrait devoir être retourné par GRE est une méthode efficace pour réduire les exigences de traitement logiciel du trafic qui serait renvoyé de l'entité WCCP. Cela est beaucoup plus efficace que de refuser le trafic sur l'entité WCCP et de le forcer à être encapsulé et renvoyé au Catalyst 6500.

N'oubliez pas que le groupe de services WCCP est évolutif. Si le trafic excédentaire est contourné en raison de la charge, ce trafic est renvoyé, ce qui crée une charge CPU sur le Catalyst 6500. Une mise à l'échelle adéquate ou même une surconsolidation du groupe de services WCCP est la seule méthode pour éviter cette situation.

Amélioration du retour de couche 2

Dans 12.2(18)SXH, une option permet à l'entité WCCP de réécrire l'adresse MAC de couche 2 plutôt que d'encapsuler le trafic de retour. Cette amélioration du retour de couche 2 (ID de bogue Cisco CSCuk59825) permet le traitement matériel du trafic retourné lorsque WCCP est configuré pour utiliser la redirection d'entrée avec affectation de masque.

Récapitulatif des options WCCP

Lorsqu'il est mis en oeuvre sur le Catalyst 6500, WCCP offre de nombreuses options de configuration, comme illustré dans ce tableau. Notez que le WCCP négocie ces options et contrôle les options utilisées par le Catalyst 6500. La configuration est effectuée du côté de l'appareil WCCP de la connexion WCCP.

Du point de vue matériel, toutes les configurations WCCP de sortie nécessitent un traitement logiciel et ont un impact sur l'utilisation du CPU. Le traitement logiciel est également nécessaire en entrée lorsque la méthode d'affectation basée sur le hachage est utilisée et qu'elle a le même impact potentiel sur l'utilisation du processeur.

La méthode recommandée de déploiement WCCP sur le Catalyst 6500 est la redirection L2 avec affectation de masque et, si disponible, le retour L2.

Astuce : Une seule option garantit des performances élevées et un transfert complet basé sur le matériel : la redirection L2 basée sur l'entrée avec affectation de masque sur Supervisor Engine 2, Supervisor Engine 32 et Supervisor Engine 720.

Recommandations de conception WCCP

Utilisez ces recommandations de configuration pour déterminer la meilleure méthode de déploiement WCCP pour votre situation.

Résumé

Concevez le réseau de sorte que l'entrée WCCP puisse être utilisée comme méthode de redirection. Une bonne méthode de conception consiste à disposer d'un bloc de commutation de mise en cache dans le cadre d'un réseau de distribution hiérarchique de couche 3 ; ainsi, le trafic WCCP traité peut être identifié sur quelques ports d'entrée principaux.

• Utilisez la plate-forme logicielle Cisco IOS 12.2(18)SXF7 ou une version plus récente.
• Identifier et rediriger le trafic sur les interfaces d’entrée.
• Utilisez des appliances WCCP qui prennent en charge la méthode de redirection L2.
• Utilisez des appliances WCCP qui prennent en charge la méthode d'affectation basée sur un masque.
• Si possible, utilisez une liste de redirection au niveau du Catalyst 6500 pour le trafic qui ne peut pas être traité par l'appliance WCCP.
• Réglez les compteurs NetFlow avec des configurations d'affectation de sortie ou de hachage avec Supervisor Engine 720.
• Les appliances WCCP doivent disposer d'un environnement L3 dédié et d'une interface SVI/VLAN.

En outre, Cisco Advanced Service recommande ces considérations de conception :

• Dans un environnement qui n'est pas entièrement redirigé de couche 2 avec affectation de masque, le Supervisor Engine 720 ne fonctionne pas mieux que la plate-forme Supervisor Engine 2. Ne mettez pas à niveau le matériel et attendez-vous à de meilleures performances dans cette situation.
• Pour les déploiements de sites centraux de grande envergure nécessitant un trafic important, envisagez une conception avec un routage basé sur des politiques (PBR) et Cisco Content Switching Model (CSM)/Application Control Engine (ACE) pour l'interception et le transfert du trafic.
• WCCPv2 fonctionne comme prévu dans des circonstances parfaites. Cependant, dans certaines circonstances, l'utilisation du processeur sur le routeur peut atteindre des niveaux élevés qui rendent le périphérique inutilisable et qui nécessitent un rechargement :
  
  
  • WCCPv2 passe du mode d'attribution de masque L2 accéléré par le matériel en entrée à tout autre mode nécessitant le processeur sur la carte MSFC.
  • WCCP n'est pas configuré correctement (par exemple, sortie au lieu d'entrée ou hachage L2 au lieu d'affectation de masque).
• Tout déploiement WCCP de volume élevé avec Catalyst 6500 (mise en cache, diffusion en continu, WAAS ou autres scénarios de « débit élevé de trafic ») doit être testé avec le trafic en direct avant le déploiement en production complète.

Recommandations supplémentaires

Utilisez une liste de redirection au niveau du commutateur afin d'éviter les paquets qui sont renvoyés au Catalyst 6500. Si l'une des règles des périphériques de cache peut être déplacée vers le Catalyst 6500 en tant que liste de redirection, cela peut fournir de meilleures performances matérielles.

Les ressources NetFlow de la plate-forme Supervisor Engine 720 peuvent être épuisées rapidement si vous utilisez une méthode autre que l'attribution de masque d'entrée-couche 2. Le Supervisor Engine 720 ne fournit pas de meilleures performances que le Supervisor Engine 2 avec une autre méthode.

Dans les cas où le Supervisor Engine 720 ou le Supervisor Engine 32 doit être utilisé dans une conception non optimale, envisagez d'utiliser la commande mls ip netflow create software-mode fast afin d'accélérer le traitement NetFlow du paquet initial WCCP. Cela supprime les améliorations ajoutées à Supervisor Engine 32 et Supervisor Engine 720 NetFlow et fournit des performances égales à celles du matériel Supervisor Engine 2 NetFlow.

La configuration d'un moteur de contenu Cisco (CE) pour l'attribution de masque est la suivante :

• wccp version 2
• liste de routeurs wccp number ip-address
• wccp service router-list-num num mask-assignation

Utilisez ces commandes afin d'examiner l'utilisation de NetFlow et de déterminer si WCCP utilise des entrées NetFlow ascendantes et utilise le traitement logiciel :

• show mls netflow table-contention detail
• show mls netflow ip sw-install
• show mls netflow aging
• show mls netflow ip dynamic count
• show mls netflow ip count
• show mls ip
• show fm netflow counters

Si vous rencontrez des problèmes de logiciel WCCP en raison de l'utilisation des ressources NetFlow, ces commandes risquent d'effacer agressivement les entrées existantes et de créer de la place pour les nouvelles entrées. (Cela n'aide pas s'il y a simplement plus d'entrées qu'il n'y a d'espace NetFlow.)

• mls aging fast time 3 threshold 1
• mls aging long 64
• mls aging normal 32
• mls ip netflow create software-mode fast (désactive certaines modifications NetFlow de Supervisor Engine 720 qui ne se trouvaient pas dans Supervisor Engine 2.)

Pour éviter les abandons de paquets, les entités WCCP doivent rediriger le trafic depuis une interface qui n'est pas l'interface sur laquelle le WCCP est configuré. Catalyst 6500 WCCP abandonne les paquets dans cette situation lorsque toutes les conditions sont remplies :

• Les clients et l'entité WCCP se trouvent sur la même interface L3.
• La stratégie de redirection WCCP est appliquée sur cette interface.
• La méthode de redirection GRE est utilisée.
• La redirection de la fragmentation des paquets est requise.
• Le Supervisor Engine 720 est utilisé.

Cette situation est due aux mécanismes de protection intégrés au Catalyst 6500 ; le logiciel Cisco IOS dispose de contrôles qui empêchent le paquet d'entrer et de quitter la même interface virtuelle du logiciel Cisco IOS où il peut potentiellement boucler et provoquer un comportement indésirable. Déplacez les appliances WCCP dans leur propre environnement L3 dédié afin d'éviter cela.

La limite de débit basée sur l'utilisateur (UBRL) et le WCCP ne fonctionnent pas simultanément sur une interface en raison de masques de flux. Il existe un masque de flux pour chaque interface de monodiffusion. WCCP nécessite un flux complet et UBRL utilise src uniquement ou dst uniquement.

La prise en charge WCCP a été ajoutée pour le retour de Supervisor Engine 2 et L2 dans 12.2(18)SXF5. Ce n'était pas dans Supervisor Engine 720 avant 12.2(18)SXH en avril/mai 2007.

Seule la redirection PFC de couche 2 WCCP est prise en charge avec l'équilibrage de charge du serveur de la plate-forme logicielle Cisco IOS (SLB) ; d'autres configurations WCCP ne sont pas compatibles et GRE ne fonctionne pas. La commande WCCP accélérée s'applique uniquement au Supervisor Engine 2/MSFC2. Son objectif est de forcer le routeur à négocier l'attribution du masque et la redirection de couche 2, ce qui signifie que toute redirection WCCP est effectuée dans le matériel. Les moteurs de supervision Supervisor Engine 32 et Supervisor Engine 720 négocient cela sans avoir besoin de cette commande.

Solutions

Note: Utilisez l'Outil de recherche de commande (clients inscrits seulement) pour obtenir plus d'informations sur les commandes utilisées dans cette section.

ACNS

Pour la redirection de la mise en cache transparente standard, rappelez-vous que l'entité WCCP fournit au routeur WCCP les méthodes prises en charge et qu'il peut être nécessaire de configurer pour cela. Pour Cisco ACNS, cet exemple de configuration demande les méthodes optimisées de redirection L2 et d'affectation basée sur des masques :

1. Assurez-vous d'avoir WCCPv2 pour les optimisations Catalyst 6500 :
   
   

   ContentEngine(config)# wccp version 2

2. Configurez une liste de routeurs qui définit les Catalyst 6500 à utiliser :
   
   

   ContentEngine(config)# wccp router-list 1 172.16.16.1

3. Configurez le service pour utiliser les méthodes d'optimisation :
   
   

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

Du côté du routeur, la conception du Catalyst 6500 doit garantir que les périphériques WCCP se trouvent sur une interface L3 dédiée qui n'est pas dans le chemin de trafic actuel (entrée ou sortie). Pour les performances matérielles, les flux de trafic doivent être capturés en entrée vers le Catalyst 6500, même si cela nécessite la configuration de plus d'interfaces que si une seule interface de sortie a été choisie. Une conception idéale agrémenterait l'ensemble du trafic avant d'atteindre ce périphérique, et seules quelques interfaces nécessiteraient la configuration d'entrée WCCP.

La configuration WCCP sur le Catalyst 6500 doit être :

1. Configurer WCCPv2 :
   
   

   6500Switch# ip wccp version {1 | 2}

2. Configurez un groupe de services WCCP.
   
   

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

   Utilisez la commande accélérée uniquement pour les plates-formes Supervisor Engine 2 avec le logiciel Cisco IOS 12.1E.

La liste de redirection est utilisée afin d'identifier le trafic qui doit être sélectionné ou non pour la redirection. Rappelez-vous que cette liste de contrôle d’accès peut être exécutée sur le matériel, ce qui est une façon beaucoup plus efficace d’empêcher la redirection du trafic qui ne peut pas être traité par le périphérique WCCP. Le trafic qui est envoyé au périphérique et ne peut pas être traité doit être renvoyé à ce Catalyst 6500 afin d'être replacé dans le chemin de trafic d'origine, ce qui nécessite un traitement supplémentaire. Les listes d’accès WCCP sont des listes d’accès standard ou étendues.

Cet exemple montre que toutes les requêtes de 10.1.1.1 à 12.1.1.1 contournent le cache et que toutes les autres requêtes sont redirigées.

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

Configurez la méthode WCCP d'entrée sur chaque interface d'entrée qui reçoit le trafic à rediriger :

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

Cette opération termine la configuration sur l'appliance WCCP et le commutateur, de sorte que la redirection du trafic doit se produire à ce stade.

Les configurations WCCP finales des périphériques ressemblent à ceci.

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

Pour vérifier cette configuration, entrez la commande suivante :

Show ip wccp service detail

Pour obtenir des options de configuration WCCP supplémentaires, telles que l'adressage de groupe à l'aide de la multidiffusion ou d'une sécurité WCCP supplémentaire, reportez-vous à Configuration des services de cache Web à l'aide de WCCP.

Commandes Show and Debug de WCCP IOS

• show ip wccp service-number - indique le nombre total de paquets redirigés. Ce nombre correspond au nombre de flux, ou sessions, qui sont redirigés.
• show ip wccp service-number detail - indique le nombre de paquets redirigés. Le nombre correspond au nombre de flux, ou sessions, qui sont redirigés.
• show ip wccp web-cache detail - fournit une indication du nombre de flux, plutôt que de paquets, qui utilisent la redirection de couche 2.
• clear ip wccp - réinitialise le compteur pour les informations 'Packets Redirect'.
• show ip wccp service-number view - affiche les périphériques WCCP qui font partie du groupe de services.
• show ip wccp service-number service - affiche le hachage, les ports et la priorité WCCP du service. Les services de priorité supérieure sont d'abord touchés lorsque plusieurs services sont configurés sur l'interface.
• debug ip wccp events - dépanne l'état du protocole WCCP.
• debug ip wccp packets - passe en revue les communications entre les entités de traitement des paquets WCCP.

Lorsque vous utilisez WCCP et le transfert matériel, certains compteurs peuvent ne pas s'afficher comme prévu :

• Si la liste de contrôle d'accès WCCP est traitée complètement dans le matériel, les compteurs WCCP peuvent ne pas afficher de nombre de paquets précis.
• Si le WCCP utilise une affectation basée sur le hachage et des ressources matérielles NetFlow, les compteurs WCCP peuvent refléter le nombre de flux au lieu du nombre de paquets.

Commandes NetFlow

Lorsque vous avez des configurations WCCP qui nécessitent l'utilisation de ressources matérielles NetFlow, utilisez ces commandes de commutation multicouche (MLS) et Fabric Manager (FM) pour vérifier l'état des ressources NetFlow :

• show mls netflow table-contention detail
• show mls netflow ip sw-install
• show mls netflow aging
• show mls netflow ip dynamic count
• show mls netflow ip count
• show mls ip
• show fm netflow counters

Défauts WCCP

Cette table des ID de bogues et des résolutions de bogues Cisco prend en charge la recommandation générale d'utiliser le logiciel Cisco IOS Version 12.2(18)SXF7 ou ultérieure pour la meilleure prise en charge de WCCP.