Commutateurs : Commutateurs Cisco Catalyst, s�rie�6500

WCCP sur des Plateformes de Catalyst 6500 avec le guide de configuration d'utilisation du CPU élevé

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

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

Le WCCP a été initialement conçu comme méthode pour intercepter le trafic web (HTTP) et en avant il à un périphérique de cache local, où il pourrait être servi à un client d'un emplacement local et économiser la bande passante BLÊME chère.

D'un point de vue d'utilisateur du réseau, le WCCP est transparent parce qu'il est utilisé au niveau du réseau, sans n'importe quelle configuration spéciale par l'utilisateur, afin d'identifier et réorienter le trafic web qui traverse un périphérique de la couche 3 (L3) à un périphérique de cache local. Bien que le WCCP ait été initialement conçu pour le trafic web, la méthode transparente de redirection est devenue un mécanisme très utile pour aborder d'autres problèmes avec le contenu à fort débit au-dessus des liens à faible volume. Pour cette raison, le support supplémentaire de protocole a été ajouté aux versions postérieures WCCP. Ces Technologies supplémentaires incluent des protocoles tels que le HTTP, le HTTPS, le FTP, le flux vidéo, et les Technologies de mise en cache de fichier, telles que le Protocole CIFS (Common Internet File System). Ces solutions et Plateformes de Cisco de support de Technologies plus nouvelles, telles que le Services de fichiers sur réseau étendu (WAFS), les Services d'applications de réseau étendu Cisco (WAAS), le réseau d'application (AONs), et les capacités améliorées du logiciel réseau d'application et de Réseau de diffusion de contenu (ACNS).

L'adoption WCCP augmente pendant que les entreprises implémentent les derniers outils de productivité tels que des transmissions et la formation basées sur la vidéo, aussi bien que vidéo vivent et sur demande. Les efforts de contrôler des coûts, tels que les centres de traitement des données consolidés, créent le besoin du WCCP de prendre en charge supplémentaire, extrêmement des services de bande passante élevée.

En raison de l'importance du WCCP avec les réseaux riches satisfaits d'aujourd'hui, quelques Plateformes, telles que le Catalyst 6500, ont mis en application la représentation assistée par le matériel avec le WCCP de sorte que le chargement CPU exigé pour le protocole soit réduit. Ce document décrit comment déployer le WCCP sur le Catalyst 6500 afin de maximiser l'utilisation de matériel et réduire le chargement CPU.

Contribué par Rahul Parameswaran et Dixon Ho, ingénieurs TAC Cisco.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

  • WCCP
  • Commutateurs de la gamme Cisco Catalyst 6500
  • Logiciel de Cisco IOS®

Composants utilisés

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
  • Version du logiciel Cisco IOS 12.1(50)SY ou plus tard avec l'engine de superviseur 2T (carte de fonctionnalité de stratégie 4)
  • Version du logiciel Cisco IOS 12.2(18)SXD1 ou plus tard avec l'engine de superviseur 720 (carte de fonctionnalité de stratégie 3)

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Présentation fonctionnelle WCCP

La fonctionnalité qui est génériquement mentionnée pendant que le WCCP implique réellement trois composants :

  1. Fonctionnalité mise en application seulement au routeur ou au commutateur
  2. Fonctionnalité mise en application seulement à l'entité de trafic-traitement, telle qu'un cache de Web
  3. WCCP mis en application des deux côtés

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

  1. La méthode d'affectation détermine quel trafic WCCP et quel périphérique WCCP sont choisis pour la destination du trafic. Le protocole WCCP prend en charge de plusieurs périphériques groupés ensemble.
  2. La méthode de redirection en avant la circulation à l'appliance WCCP quand il y a un besoin de changer du chemin réseau normal que le trafic traversait.
  3. La méthode de retour détermine comment le trafic est renvoyé au routeur de l'appliance WCCP si le trafic ne pourrait pas être entretenu. Dans les cas où l'appliance WCCP entretient la demande, les paquets sont retournés directement au demandeur.

WCCP et Catalyst 6500

Le Supervisor Engine 2 de Catalyst 6500, l'engine 32 de superviseur, et le support de l'engine 720 de superviseur ces caractéristiques et méthodes WCCP :

  • WCCP Version 2 (WCCPv2)
  • méthode parasite Information d'affectation
  • méthode basée sur masque d'affectation (matériel-accélérée)
  • Méthode de redirection de l'Encapsulation de routage générique (GRE) L3 (matériel-accélérée sur engine 32 de superviseur et engine 720 de superviseur)
  • Posez 2 la méthode de la redirection (L2) (matériel-accélérée sur le Supervisor Engine 2, l'engine 32 de superviseur, et l'engine 720 de superviseur)
  • Méthode de retour GRE
  • Méthode du retour L2 avec la version du logiciel Cisco IOS 12.2SXH (matériel-accélérée sur le Supervisor Engine 2, l'engine 32 de superviseur, et l'engine 720 de superviseur)

Pour plus de détails sur ces caractéristiques, référez-vous au WCCP de configuration dans le guide de configuration du logiciel de Cisco IOS de gamme Cisco 6500, 12.2SX.

Méthode d'affectation WCCP

L'affectation WCCP détermine quel trafic le protocole WCCP réoriente et quel entité WCCP reçoit le trafic redirigé.

Quand le WCCP est configuré sur une interface d'un routeur et sur une entité WCCP, les besoins de réorientation de périphérique (le Catalyst 6500) de connaître quel trafic doit être réorienté et où le trafic doit être envoyés. Toutes les entités WCCP dans un groupe de service groupent communiquent par le protocole WCCP avec du Catalyst 6500 ; cependant, une appliance WCCP est sélectionnée pour représenter la batterie afin de contrôler comment la batterie fonctionne (par la méthode d'affectation, méthode de redirection, et ainsi de suite). L'appliance et le routeur WCCP peuvent négocier la méthode par laquelle des paquets sont distribués entre les caches de Web dans un groupe de service. Un groupe de service est défini comme relations multiples entre jusqu'à 32 Routeurs et 32 entités WCCP. La négociation est par le groupe de service ; ainsi, les caches de Web qui participent à plusieurs groupes de service peuvent négocier une méthode différente d'affectation pour chaque groupe de service. Les services actuellement disponibles WCCP sont :

Service WCCPProtocol
cache de WebHTTP
53Cache DNS
60FTP
61WAAS - expédiez
62WAAS - renversez
70HTTPS
80Protocole RTSP (Real-Time Streaming Protocol)
81Microsoft Media Server (MMS) au-dessus de l'UDP (MMSU)
82MMS au-dessus du TCP (MMST)
83RTSP utilisant l'UDP (RTSPU)
89Protocole CIFS-cache WAAS
98Cache de Web fait sur commande
99Proxy inverse
90-97Utilisateur-configurable *

* des services Utilisateur-configurables sont mis en application dans le Catalyst 6500 avec une commande de niveau d'interface appliquée à un d'arrivée ou à une direction sortante. Les implications du choix d'arrivée ou de sortant sont discutées plus tard, mais d'arrivée est la méthode préférée parce qu'une liste de réorientation peut être ajoutée au WCCP pour la représentation maximum de matériel.

Une fois configuré pour le WCCP, un routeur annonce les méthodes prises en charge d'affectation pour un groupe de service dans les messages de transmissions WCCP. L'absence d'un tel message implique que le Catalyst 6500 prend en charge la méthode parasite information par défaut d'affectation seulement.

Une fois la négociation entre le Catalyst 6500 et l'appliance WCCP est complète, l'entité indiquée par WCCP, par le WCCP, informe le Catalyst 6500 quel trafic doit être réorienté et à quel entités WCCP le trafic est assigné. Comme exemple, l'entité WCCP peut informer le Catalyst 6500 pour réorienter tout le trafic web d'un sous-réseau particulier aux moteurs de cache 1 - 4 dans le groupe de service quand il y a plus de quatre périphériques WCCP disponibles.

Il y a deux méthodes d'affectation disponibles pour le WCCP :

  1. l'affectation parasite Information (par défaut) utilise un algorithme de hachage articulé autour d'un logiciel avec des directives de l'appliance WCCP-indiquée afin de déterminer quelle appliance WCCP reçoit le trafic. Dans une engine 32 de superviseur ou la plate-forme de l'engine 720 de superviseur, des ressources en matériel de NetFlow sont utilisées afin d'appliquer un certain niveau d'aide de matériel.
  2. l'affectation basée sur masque utilise les capacités matérielles du Catalyst 6500, spécifiquement la mémoire associative ternaire de liste de contrôle d'accès (ACL) (TCAM), afin d'assigner le trafic aux entités WCCP. C'est la méthode préférée.

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

Détail parasite Information de méthode d'affectation

Le mécanisme parasite information d'affectation se fonde sur un algorithme exécuté en logiciel. Afin d'accroître l'algorithme de hachage, le premier paquet dans un flux particulier est envoyé du chemin de matériel au chemin logiciel où les informations parasites sont exécutées.

Le logiciel exécute des informations parasites XOR de divers composants de l'écoulement et fournit des informations parasites qui séparent la circulation aux diverses entités WCCP. Le mécanisme d'informations parasites détermine comment le trafic est distribué parmi les entités disponibles WCCP.

Le résultat d'informations parasites est programmé dans la table de NetFlow de matériel où des paquets suivants dans cet écoulement sont expédiés. Indépendamment des champs disponibles pour hacher par WCCP, le plein cinq-tuple est utilisé. Ceci signifie que le NetFlow est mis dans l'interface, mode de flux complet quand le WCCP est activé. Ceci a des implications sur d'autres caractéristiques qui peuvent exiger des ressources en NetFlow. Voyez la section de défauts WCCP pour plus de détails.

Une question commune au sujet de WCCP sur le Catalyst 6500 est, « pourquoi fait l'augmentation d'utilisation du processeur quand j'active le WCCP ? » Quand les affectations parasites information sont en service, le traitement articulé autour d'un logiciel du paquet initial dans chaque écoulement place une charge sur la CPU et est le plus souvent la cause de l'utilisation accrue. Avec le matériel actuellement disponible d'expédition du Policy Feature Card 3 (PFC3), si le WCCP est configuré comme caractéristique de sortie ou si l'affectation parasite information est en service (d'entrée ou de sortie), un certain niveau du traitement de logiciel est toujours exigé.

L'utilisation de la méthode parasite information d'affectation affecte ces caractéristiques :

  • Table de NetFlow - Le nombre d'entrées prises en charge par le PFC est limité, et les modifications de masque de flux pour relier à plein régime pour la table entière de NetFlow.
  • Utilisation du processeur - Il y a une augmentation de l'utilisation du processeur car le premier paquet dans chaque écoulement est logiciel commuté.
  • Représentation - Le débit auquel le trafic est envoyé à la CPU pour la consultation est limité de sorte que la CPU soit protégée.
  • Fonctions NetFlow - D'autres caractéristiques qui utilisent des ressources en NetFlow pourraient être affectées si les ressources en NetFlow sont consommées par WCCP.

Les limites et les implications provoquées par la condition requise parasite information d'affectation pour le traitement de logiciel s'appliquent au d'entrée et au trafic en sortie. L'incidence sur la CPU peut être aggravée si le réseau subit les structures de trafic atypiques, telles qu'une attaque du Déni de service (DOS). Dans une épidémie typique d'attaque ou de ver, chaque paquet envoyé par un hôte est à une nouvelle destination ou port, qui causent chaque paquet d'être traité en logiciel. Puisque le trafic redirigé WCCP explicitement est envoyé à la CPU pour le premier-paquet traitant, il y a des méthodes limitées de protection. L'utilisation de « refusent » des rubriques de liste ACL sur l'interface peut limiter ce qui est envoyé à la CPU ; cependant, il n'y a aucune débit-borne ou d'autres protections contre ces types d'attaques.

Détail basé sur masque de méthode d'affectation

l'affectation basée sur masque dépend différemment manipulé de si elle est configurée sur le d'entrée ou sur le de sortie.

Avec l'affectation basée sur masque d'entrée, le masque est programmé dans l'ACL TCAM avant le transfert de paquet, ainsi le traitement de table et de logiciel de NetFlow ne sont pas nécessaire. L'entité WCCP choisit un certain nombre d'information-positions et assigne un masque d'adresse et l'appliance WCCP dans chaque position. Une fois que les affectations sont complètes, le superviseur programme une entrée TCAM et une contiguïté de matériel pour chaque position et réoriente les paquets qui apparient le masque d'adresse à l'appliance associée WCCP au moyen d'une réécriture L2.

Si le WCCP est configuré comme caractéristique d'entrée, il peut utiliser une entrée de réorienter-contiguïté d'ACL dans la table d'ACL de matériel. Une fois le WCCP apparie l'entrée, il emploie une contiguïté appropriée afin d'effectuer l'un ou l'autre une réécriture L2 ou l'encapsulation GRE. Ainsi, quand l'affectation de masque est utilisée sur le d'entrée, la réécriture les deux L2 (Supervisor Engine 2, engine 32 de superviseur, et engine 720 de superviseur) et l'encapsulation GRE (engine 32 de superviseur et engine 720 de superviseur seulement) sont effectuées dans le matériel.

Si le WCCP est configuré comme caractéristique de sortie, des réorienter-contiguïtés d'ACL ne sont pas prises en charge dans le matériel parce que les paquets dans l'écoulement ont été déjà conduits par le système. Le premier paquet d'un écoulement est envoyé au logiciel pour le traitement. Une fois que la réorienter-contiguïté appropriée est déterminée, elle est programmée dans le matériel de NetFlow (au lieu d'ACL TCAM), où les points d'entrée à une contiguïté qui effectue l'un ou l'autre une réécriture L2 ou l'encapsulation GRE. Des paquets suivants dans l'écoulement sont réorientés dans le matériel par le matériel de NetFlow.

Remarque: Si le WCCP est configuré comme caractéristique de sortie, l'affectation de masque exige le logiciel traitant, qui réalise une inversion n'importe quel avantage de la méthode basée sur masque d'affectation.

Des deux options basées sur masque, seulement l'affectation basée sur masque d'entrée active le plein expédition réalisé par matériel pour l'initiale et les paquets suivants. N'importe quelle autre option, telle que l'utilisation de l'affectation ou du de sortie parasite information traitant, commutation de logiciel de causes du paquet initial et matériel-NetFlow a commuté l'expédition des paquets suivants.

Méthode de redirection WCCP

L'entité WCCP, pas le Catalyst 6500, dicte les tables de hachage et le masque/valeur place au Catalyst 6500, ainsi la configuration de la méthode de réorientation est faite sur cette appliance, et pas sur le commutateur de Catalyst 6500. Le Catalyst 6500 détermine le meilleur réorientent la méthode disponible, basé sur les transmissions WCCP avec l'entité/groupe WCCP. Cette négociation détermine comment le trafic redirigé est expédié à l'appliance. Il y a deux options de redirection : L3 (GRE) et L2 (réécritures d'adresse MAC).

Avec WCCPv1, la seule option est la redirection L3, également connue sous le nom d'encapsulation GRE. Avec la redirection L3, chaque WCCP paquet réorienté est encapsulé dans une en-tête GRE identifiée par un type de protocole 0x883E suivi d'un quatre-octet que le WCCP réorientent l'en-tête, qui est ultérieurement envoyée à l'appliance WCCP (telle qu'un moteur de cache).

Avec l'introduction de WCCPv2, la redirection L2, également connue sous le nom de redirection accélérée WCCP, a été ajoutée afin de tirer profit des Plateformes de commutation de matériel telles que le Catalyst 6500. Quand le WCCP utilise la redirection L2, l'appliance et le Catalyst 6500 WCCP doivent être L2 adjacent (dans le même L2 VLAN). Le trafic L2 réorienté n'utilise pas l'encapsulation GRE ; au lieu de cela, l'Adresse MAC de destination est réécrite par le Catalyst 6500 à celle de l'entité L2-connected WCCP et expédiée par la commutation normale de matériel.

Remarque: La méthode d'expédition au périphérique WCCP peut ne pas être la même méthode qui les utilisations de périphérique WCCP afin d'envoyer le trafic de nouveau au Catalyst 6500. Le WCCP est utilisé afin de négocier une méthode en avant et de retour que les deux périphériques prennent en charge. Voir la méthode de retour WCCP.

Méthode de l'expédition L3 (GRE)

116134-config-wccp-6500-01.jpg

L'exécution WCCP L3 comporte l'utilisation de GRE comme méthode d'encapsulation. Des paquets réorientés sont encapsulés dans une en-tête GRE avec un type de protocole de 0x883e, avec une en-tête de redirection 4-byte WCCP qui inclut une position d'ID et d'informations parasites de service appariée (WCCPv2 seulement). L'utilisation de GRE permet au client WCCP d'être séparé du Catalyst 6500 par des sauts du multiple L3 (conduit).

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

  1. D'entrée - Redirection L3 (GRE) + affectation d'informations parasites ; ceci exige le traitement de logiciel.
  2. D'entrée - Redirection L3 (GRE) + affectation de masque ; ceci exige le plein matériel traitant et est disponible seulement sur l'engine 32 de superviseur ou l'engine 720 de superviseur.
  3. De sortie - Redirection L3 (GRE) + affectation d'informations parasites ; ceci exige le traitement de logiciel.
  4. De sortie - Redirection L3 (GRE) + affectation de masque ; ceci exige le traitement de logiciel.

D'entrée - Redirection L3 (GRE) + affectation d'informations parasites

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

Avec la méthode parasite information d'affectation, l'engine 32 de superviseur et l'engine 720 de superviseur en avant le premier paquet de chaque écoulement en logiciel de sorte qu'une entrée de table de NetFlow soit établie. Le paquet est alors encapsulé dans GRE (l'encapsulation et l'expédition du paquet initial est fait en logiciel) et est expédié à l'appliance WCCP.

L'établissement de l'entrée de NetFlow affecte l'utilisation du processeur, mais l'expédition de paquet suivant est fait dans le matériel pour l'engine 720 de superviseur et l'engine 32 de superviseur. Les structures de trafic, particulièrement le nombre de seuls écoulements, dictent combien la CPU est utilisée. Si les ressources de NetFlow en Catalyst 6500 sont consommées, alors tout le trafic est expédié en logiciel.

Les ressources en NetFlow du superviseur PFC diffèrent à travers de diverses Plateformes. Actuellement, les plus grandes ressources en NetFlow sont disponibles sur le PFC-3BXL sur la plate-forme de l'engine 720 de superviseur.

D'entrée - Redirection L3 (GRE) + affectation de masque

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

Avec la méthode basée sur masque d'affectation, l'engine 32 de superviseur et l'engine 720 de superviseur en avant l'initiale et les paquets suivants dans le matériel, parce que GRE est pris en charge à la façon des indigènes, et l'affectation de masque utilise le matériel de l'ACL TCAM pour la transmission.

De sortie - Redirection L3 (GRE) + affectation d'informations parasites

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

Avec la méthode parasite information d'affectation avec l'engine 32 de superviseur et l'engine 720 de superviseur, le Catalyst 6500 en avant le paquet initial de chaque écoulement en logiciel de sorte que l'entrée de table de NetFlow soit établie. Le paquet est alors encapsulé dans GRE et expédié à l'entité WCCP.

L'établissement de l'entrée de NetFlow affecte l'utilisation du processeur, mais l'expédition de paquet suivant est fait dans le matériel. Les structures de trafic, particulièrement le nombre de seuls écoulements, dictent combien la CPU est utilisée. Si les ressources de NetFlow en Catalyst 6500 sont consommées, alors tout le trafic est expédié en logiciel.

Les ressources en NetFlow du superviseur PFC diffèrent à travers les diverses Plateformes. Actuellement, les plus grandes ressources en NetFlow sont disponibles sur le PFC-3BXL sur la plate-forme de l'engine 720 de superviseur.

De sortie - Redirection L3 (GRE) + affectation de masque

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

Avec la méthode basée sur masque d'affectation avec l'engine 32 de superviseur et l'engine 720 de superviseur, le premier paquet de chaque écoulement est logiciel commuté de sorte que l'entrée de table de NetFlow soit établie. Aucun des superviseurs ne prend en charge la contiguïté d'ACL de sortie programmant, qui force ce logiciel traitant et utilise des ressources en NetFlow (au lieu d'ACL TCAM de matériel) pour le paquet initial dans chaque écoulement. Le paquet est alors encapsulé dans GRE et expédié à l'appliance WCCP.

L'établissement de l'entrée de NetFlow affecte l'utilisation du processeur, mais l'expédition de paquet suivant est fait dans le matériel. Les structures de trafic, particulièrement le nombre de seuls écoulements, dictent combien la CPU est utilisée. Si les ressources de NetFlow en Catalyst 6500 sont consommées, alors tout le trafic est expédié en logiciel.

Les ressources en NetFlow du superviseur PFC diffèrent à travers les diverses Plateformes. Actuellement, les plus grandes ressources en NetFlow sont disponibles sur le PFC-3BXL sur la plate-forme de l'engine 720 de superviseur.

Méthode de l'expédition L2

Avec l'expédition L2, les entités WCCP (ACNS, WAFS, WAAS, et ainsi de suite) dans un groupe de service font partie du même sous-réseau et sont L2 à côté du Catalyst 6500. Ceci active le débit élevé, basse redirection de latence du trafic. L'interface d'entrée (où le WCCP est configuré) et l'interface où les appliances WCCP se trouvent doivent être sur différents VLAN.

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

Remarque: La méthode d'expédition au périphérique WCCP peut ne pas être la même méthode qui les utilisations de périphérique WCCP afin d'envoyer le trafic de nouveau au Catalyst 6500. Le WCCP est utilisé afin de négocier une méthode en avant et de retour que les deux périphériques prennent en charge. Voir la méthode de retour WCCP.

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

  • D'entrée - Redirection L2 + affectation d'informations parasites ; ceci exige le traitement de logiciel.
  • D'entrée - La redirection L2 + l'affectation de masque ceci exige le plein matériel traitant et est recommandée.
  • De sortie - Redirection L2 + affectation d'informations parasites ; ceci exige le traitement de logiciel.
  • De sortie - Redirection L2 + affectation de masque ; ceci exige le traitement de logiciel.

D'entrée - L2 + affectation d'informations parasites

Une fois configuré sur le d'entrée avec L2 + affectation d'informations parasites, le trafic WCCP envoie le premier paquet dans chaque écoulement pour être un logiciel commuté, qui crée une entrée de NetFlow dans la table de NetFlow de matériel.

Remarque: Le masque de flux de NetFlow est placé pour relier le mode de flux complet, qui pourrait affecter d'autres fonctions NetFlow configurées sur le commutateur.

Puisque le WCCP est un mécanisme sans état, les informations ne sont pas mises à jour en logiciel ; en revanche, on le met à jour dans le matériel comme des entrées dans la table de NetFlow. Le trafic ultérieur dans l'écoulement est expédié dans le matériel tant que une entrée de table de NetFlow existe.

L'établissement de l'entrée de NetFlow affecte l'utilisation du processeur, mais l'expédition de paquet suivant est fait dans le matériel. Les structures de trafic, particulièrement le nombre de seuls écoulements, dicte combien la CPU est utilisée. Si les ressources de NetFlow en Catalyst 6500 sont consommées, alors tout le trafic est expédié en logiciel.

Les ressources en NetFlow du superviseur PFC diffèrent à travers les diverses Plateformes. Actuellement, les plus grandes ressources en NetFlow sont disponibles sur le PFC-3BXL sur la plate-forme de l'engine 720 de superviseur.

D'entrée - L2 + affectation de masque

Une fois configuré sur le d'entrée, L2 + affectation de masque est la méthode WCCP la plus efficace prise en charge sur le Catalyst 6500. Tout le trafic est matériel commuté, y compris le paquet initial dans chaque écoulement. Aucune redirection de logiciel n'est exigée ; l'initiale et l'expédition de paquet suivant sont fournis par le matériel.

Les ressources de l'ACL TCAM de matériel en Catalyst 6500 sont utilisées afin de préprogrammer les entrées de matériel avant que tous les paquets WCCP soient reçus.

Afin d'utiliser cette méthode et utiliser la pleine commutation de matériel, l'entité WCCP doit également prendre en charge L2 réorientent et la méthode basée sur masque d'affectation. La configuration de cette méthode est terminée sur l'entité WCCP, et le Catalyst 6500 négocie la meilleure méthode pendant les transmissions d'initiale WCCP avec l'entité/groupe WCCP.

De sortie - L2 + affectation d'informations parasites

Avec le de sortie L2 + affectation d'informations parasites, le trafic WCCP envoie le premier paquet dans chaque écoulement pour être un logiciel commuté, qui crée une entrée de NetFlow dans la table de NetFlow de matériel.

Remarque: Le masque de flux de NetFlow est placé pour relier le mode de flux complet, qui pourrait affecter d'autres fonctions NetFlow configurées sur le commutateur.

Supplémentaire, une fois configurée dans la direction de sortie, une consultation supplémentaire de Forwarding Information Base (FIB) est exigée sur le premier paquet de l'écoulement afin de déterminer la contiguïté associée avec du CE, qui exige le recyclage de paquet dans le Catalyst 6500. Les paquets suivants sont NetFlow commuté dans le matériel.

L'établissement de l'entrée de NetFlow affecte l'utilisation du processeur, mais l'expédition de paquet suivant est fait dans le matériel. Les structures de trafic, particulièrement le nombre de seuls écoulements, dicte combien la CPU est utilisée. Si les ressources de NetFlow en Catalyst 6500 sont consommées, alors tout le trafic est expédié en logiciel.

Les ressources en NetFlow du superviseur PFC diffèrent à travers les diverses Plateformes. Actuellement, les plus grandes ressources en NetFlow sont disponibles sur le PFC-3BXL sur la plate-forme de l'engine 720 de superviseur.

De sortie - L2 + affectation de masque

Une fois configuré dans la direction de sortie, L2 + affectation de masque commute le premier paquet dans chaque écoulement en logiciel, juste comme L2 + cas d'affectation d'informations parasites. Les paquets suivants sont NetFlow commuté dans le matériel.

Remarque: Le masque de flux de NetFlow est placé pour relier le mode de flux complet, qui pourrait affecter d'autres fonctions NetFlow configurées sur le commutateur.

Le PFC2 et les PFC3 ne prennent en charge pas la contiguïté d'ACL de sortie programmant, qui force le logiciel traitant pour le paquet initial dans chaque écoulement ; des paquets suivants dans l'écoulement sont expédiés dans le matériel.

L'établissement de l'entrée de NetFlow affecte l'utilisation du processeur, mais l'expédition de paquet suivant est fait dans le matériel. Les structures de trafic, particulièrement le nombre de seuls écoulements, dicte combien la CPU est utilisée. Si les ressources de NetFlow en Catalyst 6500 sont consommées, alors tout le trafic est expédié en logiciel.

Les ressources en NetFlow du superviseur PFC diffèrent à travers les diverses Plateformes. Actuellement, les plus grandes ressources en NetFlow sont disponibles sur le PFC-3BXL sur la plate-forme de l'engine 720 de superviseur.

Méthode de retour WCCP

L'entité WCCP peut entretenir la demande

Quand le WCCP est utilisé pour intercepter le trafic et l'entité WCCP exécute une exécution complète sur ces paquets, les paquets sont alors prêts à être renvoyés au client du périphérique WCCP. Ce trafic normalement traité, qui est destiné de nouveau au client sur le réseau, n'exige aucune encapsulation spéciale une fois renvoyé hors du périphérique WCCP vers le client.

Puisque l'interception WCCP a eu comme conséquence la demande de client étant avec succès entretenue (fichier de cache, flot fendu de cache, fichier de WAAS), elle peut être renvoyée au réseau en tant que trafic normal avec l'adresse de destination dans les paquets étant le demandeur d'origine. Ce trafic peut être normalement L3/switched par le Catalyst 6500 s'il est dans le chemin réseau de l'appliance WCCP au client ; avec un L2 l'appliance reliée WCCP, le trafic est dans le chemin réseau. Aucune encapsulation n'est nécessaire afin de le renvoyer du périphérique WCCP au Catalyst 6500 parce que la destination est maintenant le client d'origine au lieu d'un serveur sur l'Internet ou l'intranet. Le réseau alors manipule ceci comme n'importe quel autre écoulement du trafic IP et emploie l'expédition de matériel dans le Catalyst 6500 afin de renvoyer le trafic demandé au client.

L'entité WCCP ne peut pas entretenir la demande

Dans certains cas où l'entité WCCP ne peut pas exécuter l'opération demandée, l'appliance WCCP peut devoir envoyer le trafic de nouveau au Catalyst 6500 et préserver la destination d'origine des paquets. La transmission de ce trafic de l'entité WCCP sans encapsulation peut avoir comme conséquence des boucles du trafic. Afin de masquer un service infructueux tentez du client et envoyez les paquets à la destination d'origine à entretenir, les paquets doit rester sans changement, soit placé de nouveau dans leur chemin de transfert d'origine, et expédié sans interception WCCP à la destination d'origine.

Dans la méthode de retour WCCP, le WCCP peut être utilisé pour encapsuler ces paquets, les envoient de nouveau au périphérique qui les a interceptés en premier lieu, décolle n'importe quelle encapsulation, et les place de nouveau dans le chemin de transfert duquel ils ont été interceptés. Ces paquets doivent être envoyés normalement comme si ils n'ont été jamais interceptés par WCCP.

Les exemples de ces cas incluent :

  • Le cache a surchargé le trafic, où le trafic est sauté
  • Règles sur les périphériques de cache qui refusent l'entité WCCP d'entretenir le trafic
  • Le trafic sauté qui recherche un service non disponible sur le périphérique

À ce moment, cette méthode de retour peut être faite seulement avec l'encapsulation GRE et n'est pas encore prise en charge dans n'importe quel matériel de Catalyst 6500. Si un grand nombre de trafic sont renvoyés au Catalyst 6500 avec cette méthode, l'utilisation du CPU élevé pourrait se produire parce que ce trafic est traité en logiciel. Dans la version du logiciel Cisco IOS 12.1(18)SXH, il y a une méthode du retour L2 prise en charge par le matériel de Catalyst 6500.

Retour GRE

Dans des versions logicielles de Cisco IOS plus tôt que 12.2(18)SXH, la seule méthode de retour prise en charge pour le Catalyst 6500 est encapsulation GRE. En plus de l'en-tête GRE ajoutée au trafic de retour, une en-tête WCCP est également ajoutée. Bien que GRE soit pris en charge à la façon des indigènes dans l'engine 32 de superviseur et le matériel de l'engine 720 de superviseur, cette en-tête supplémentaire a comme conséquence le GRE n'étant pas assisté par le matériel. Notez que le Catalyst 6500 et l'appliance WCCP doivent prendre en charge et négocier la méthode du retour L2.

Aucun support matériel GRE n'existe dans le Supervisor Engine 2 pour n'importe quel GRE, d'entrée, de sortie, ou retour WCCP. Afin de traiter ce type de De-encapsulation GRE, les programmes logiciels de Cisco IOS la recevoir-contiguïté de tunnel WCCP GRE sur le WCCP ont permis à l'interface d'indiquer le processeur d'artère (RP), qui des résultats dans le traitement de logiciel du trafic de retour.

L'utilisation du du réorientation des listes au Catalyst 6500 afin d'éviter le trafic qui peut devoir être retourné par GRE est une méthode efficace pour réduire le logiciel traitant les conditions requises du trafic qui seraient renvoyées de l'entité WCCP. C'est beaucoup plus efficace qu'ayant le trafic refusé sur l'entité WCCP et le forçant pour être GRE encapsulé et renvoyé au Catalyst 6500.

Souvenez-vous que le groupe de service WCCP est extensible. Si le trafic excédentaire doit sauté charger, alors ce trafic est renvoyé, qui crée le chargement CPU sur le Catalyst 6500. L'évolution ou même overbuilding appropriée du groupe de service WCCP est la seule méthode pour éviter cette situation.

Amélioration du retour L2

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

Résumé des options WCCP

Une fois mis en application sur le Catalyst 6500, le WCCP offre beaucoup d'options de configuration, suivant les indications de cette table. Notez que l'appliance WCCP négocie ces options et contrôles que des options sont utilisé par le Catalyst 6500. La configuration est faite du côté d'appareils WCCP de la connexion WCCP.

Réorientez la méthodeAffectation
Méthode
Entrée
De sortie
Résultat de changement
L2Informations parasitesD'entréeTraitement de logiciel
(recommandé) L2MasqueD'entréePlein matériel traitant avec l'ACL TCAM
L2Informations parasitesDe sortieTraitement de logiciel
L2MasqueDe sortieTraitement de logiciel
GREInformations parasitesD'entréeTraitement de logiciel
GRE (PFC3 ou plus nouveau)MasqueD'entréePlein matériel traitant avec le NetFlow à plein régime
GREInformations parasitesDe sortieTraitement de logiciel
GREMasqueDe sortieTraitement de logiciel

D'un point de vue de matériel, toutes les configurations du de sortie WCCP exigent le traitement de logiciel et l'utilisation du processeur d'incidence. Le traitement de logiciel est également exigé sur le d'entrée quand la méthode parasite information d'affectation est utilisée et a comme conséquence le même impact potentiel sur l'utilisation du processeur.

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

Conseil : Seulement une option assure des hautes performances, plein expédition réalisé par matériel : la redirection L2 basée sur d'entrée avec l'affectation de masque sur le Supervisor Engine 2, l'engine 32 de superviseur, et l'engine 720 de superviseur.

Recommandations de conception WCCP

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

Résumé

Concevez le réseau tels que le d'entrée WCCP peut être utilisé comme méthode de redirection. Une bonne méthode de conception est d'avoir un switchblock de mise en cache en tant qu'élément d'un hiérarchique, réseau de la distribution L3 ; ceci s'assure que le trafic service par WCCP peut être identifié à quelques ports d'entrée importants.

  • Utilisation 12.2(18)SXF7 ou plus nouveau logiciel de Cisco IOS.
  • Identifiez et réorientez le trafic sur des interfaces d'entrée.
  • Utilisez les appliances WCCP qui prennent en charge le L2 réorientent la méthode.
  • Utilisez les appliances WCCP qui prennent en charge la méthode basée sur masque d'affectation.
  • Si possible, utilisez une liste de réorientation au Catalyst 6500 pour le trafic qui ne peut pas être entretenu par l'appliance WCCP.
  • Tordez les temporisateurs de NetFlow avec le de sortie ou toutes les configurations parasites information d'affectation avec l'engine 720 de superviseur.
  • Les appliances WCCP devraient avoir un environnement L3 dédié et l'interface SVI/VLAN.

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

En outre, le service avancé de Cisco recommande ces considérations de conception :

  • Dans un environnement qui n'est pas entièrement L2 réorientent avec l'affectation de masque, le superviseur que l'engine 720 n'exécute pas mieux que la plate-forme de Supervisor Engine 2. N'améliorez pas le matériel et attendez-vous à de meilleures performances dans cette situation.
  • Pour des déploiements de grand, principal lieu d'exploitation avec des conditions requises en matière de trafic à fort débit, considérez une conception avec la Gestion de réseau à base de règles et l'engine de contrôle du modèle de commutation de contenu de Cisco (CSM) /Application (ACE) pour l'interception et l'expédition du trafic.
  • Fonctions WCCPv2 comme prévues sous des circonstances parfaites. Cependant, dans certaines circonstances, l'utilisation du processeur sur le routeur peut atteindre les hauts niveaux qui rendent le périphérique inutilisable et qui exigent la recharge :

    • WCCPv2 tombe de retour du mode basé sur masque de l'affectation L2 matériel-accéléré par d'entrée dans n'importe quel autre mode qui exige la CPU sur le MSFC.
    • Le WCCP est inexactement configuré (par exemple, de sortie au lieu d'entrée ou d'informations parasites L2 au lieu d'affectation de masque).
  • N'importe quel déploiement du grand volume WCCP avec du Catalyst 6500 (mise en cache, couler, WAAS, ou d'autres scénarios « de débit du trafic élevé ») devrait être représentation testée avec le trafic vivant avant plein déploiement de production.

Recommandations supplémentaires

Employez une liste de réorientation sur le commutateur afin d'éviter les paquets qui sont renvoyés au Catalyst 6500. Si des règles des périphériques de cache peuvent être déplacées au Catalyst 6500 pendant qu'une liste de réorientation, ceci peut fournir une meilleure représentation de matériel.

Des ressources en NetFlow sur la plate-forme de l'engine 720 de superviseur peuvent être épuisées rapidement si vous utilisez n'importe quelle méthode autre que l'affectation du masque ingress-L2. L'engine 720 de superviseur ne fournit à de meilleures performances que le Supervisor Engine 2 aucune autre méthode.

Dans les cas où l'engine 720 de superviseur ou l'engine 32 de superviseur doit être utilisée dans une conception non-optimale, considérez l'utilisation de la commande rapide de logiciel-mode de création de NetFlow de mls ip de sorte que le traitement de NetFlow du paquet initial WCCP puisse être accéléré. Ceci retire les améliorations ajoutées à l'engine 32 de superviseur et au NetFlow de l'engine 720 de superviseur et fournit des performances égales à celle du matériel de NetFlow de Supervisor Engine 2.

La configuration pour une engine de contenu de Cisco (CE) pour l'affectation de masque est :

  • version 2 de wccp
  • IP address de numéro de liste de routeur de wccp
  • numériques routeur-liste-numériques de service de wccp masque-assignent

Employez ces commandes afin de passer en revue l'utilisation de NetFlow et déterminer si le WCCP épuise des entrées de NetFlow et utilise le traitement de logiciel :

  • table-conflit de show mls netflow détaillé
  • show mls netflow ip sw-installed
  • vieillissement de show mls netflow
  • compte de show mls netflow ip dynamic
  • compte de show mls netflow ip
  • show mls ip
  • compteurs de show fm netflow

Si vous éprouvez des problèmes logiciels WCCP parce que les ressources en NetFlow sont consommées, ces commandes pourraient agressivement effacer les entrées existantes et créer la pièce pour de nouvelles entrées. (Ceci n'aide pas s'il y a simplement plus d'entrées qu'il y a l'espace de NetFlow.)

  • seuil 1 du temps 3 de mls aging fast
  • mls aging long 64
  • mls aging normal 32
  • logiciel-mode de création de NetFlow de mls ip rapide (ceci désactive quelques modifications de NetFlow de l'engine 720 de superviseur qui n'étaient pas dans l'engine 2. de superviseur)

Pour éviter des pertes de paquets, les entités WCCP doivent réorienter le trafic hors d'une interface qui n'est pas l'interface que le WCCP est configuré en fonction. Le Catalyst 6500 WCCP relâche des paquets dans cette situation quand toutes les conditions sont remplies :

  • Les clients et l'entité WCCP sont 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 réorientation de la fragmentation de paquets est exigée.
  • L'engine 720 de superviseur est utilisée.

Cette situation est provoqué par par des mécanismes de protection incorporés au Catalyst 6500 ; le logiciel de Cisco IOS a les contrôles qui empêchent le paquet d'écrire et de laisser la même interface virtuelle de logiciel de Cisco IOS où il pourrait potentiellement faire une boucle et entraîner le comportement non souhaité. Déplacez les appliances WCCP à leur propre environnement L3 dédié afin d'empêcher ceci.

la limitation de débit utilisateur Utilisateur (UBRL) et le WCCP ne fonctionnent pas simultanément sur une interface en raison des flowmasks. Il y a un flowmask pour chaque interface pour chaque fonction de monodiffusion. Le WCCP exige à plein régime, et UBRL utilise réservé src ou réservé dst.

Le support WCCP a été ajouté pour le Supervisor Engine 2 et le retour L2 dans 12.2(18)SXF5. Ce n'était pas dans l'engine 720 de superviseur jusqu'à 12.2(18)SXH en avril /May 2007.

Seulement la redirection WCCP L2 PFC est prise en charge avec l'Équilibrage de charge de serveur (SLB) de logiciel de Cisco IOS ; d'autres configurations WCCP ne sont pas compatibles, et GRE ne fonctionne pas. La commande accélérée par WCCP applique seulement à l'engine 2/MSFC2 de superviseur. Son but est de forcer le routeur pour négocier l'affectation de masque et L2 réorientent, ainsi il signifie que toute la redirection WCCP est faite dans le matériel. L'engine 32 de superviseur et l'engine 720 de superviseur négocient ceci sans besoin de cette commande.

Solutions

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

ACNS

Pour la redirection transparente standard de mise en cache, rappelez-vous que l'entité WCCP fournit au routeur WCCP les méthodes prises en charge et peut devoir être configurée pour faire ainsi. Pour Cisco ACNS, cet exemple de configuration demande le L2-redirect optimisé et les méthodes basées sur masque d'affectation :

  1. Assurez que vous avez WCCPv2 pour les optimisations de Catalyst 6500 :

    ContentEngine(config)# wccp version 2
  2. Configurez une liste de routeur qui définit le Catalyst 6500s pour l'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é routeur, la conception de Catalyst 6500 devrait s'assurer que les périphériques WCCP sont sur une interface L3 dédiée qui n'est pas dans le chemin en cours du trafic (d'entrée ou de sortie). Pour la représentation de matériel, la circulation devrait être d'arrivée capturé au Catalyst 6500, même si ceci exige la configuration de plus d'interfaces que si une interface de sortie simple était choisie. Une conception idéale agrégerait tout le trafic avant d'atteindre ce périphérique, et seulement quelques interfaces exigeraient la configuration d'entrée WCCP.

La configuration WCCP sur le Catalyst 6500 devrait être :

  1. Configurez WCCPv2 :

    6500Switch# ip wccp version {1 | 2}
  2. Configurez un groupe de service WCCP.

    6500Switch (config)# ip wccp service [accelerated] redirect-list access-list
    Utilisez la commande accélérée seulement pour des Plateformes de Supervisor Engine 2 avec le logiciel du Cisco IOS 12.1E.

La liste de réorientation est utilisée afin d'identifier le trafic qui devrait être sélectionné ou non sélectionné pour la redirection. Rappelez-vous que cet ACL peut être exécuté dans le matériel, qui est beaucoup plus de façon efficace d'empêcher la redirection pour le trafic qui ne peut pas être entretenu par le périphérique WCCP. Trafiquez qui est envoyé au périphérique et ne peut pas être entretenu là doit être retourné à ce Catalyst 6500 afin de pour être mis de nouveau dans le chemin d'origine du trafic, qui exige le traitement supplémentaire. Les Listes d'accès WCCP sont standard ou des listes d'accès étendues.

Cet exemple prouve que toutes les demandes de 10.1.1.1 à 12.1.1.1 sautent le cache et que toutes autres demandes sont réorienté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 du d'entrée WCCP sur chaque interface d'entrée qui reçoit le trafic à réorienter :

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

Ceci se termine la configuration sur l'appliance WCCP et le commutateur, ainsi la redirection du trafic devrait se produire en ce moment.

Les configurations de la finale WCCP des périphériques ressemblent à ceci.

PériphériqueConfiguration
Appliance WCCP
wccp version 2
wccp router-list 1 router-ip-addresses
wccp service router-list-num 1 l2-redirect mask assign
Routeur 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
Routeur WCCP :
chaque interface d'entrée
ip wccp redirect service in

Pour vérifier cette configuration, sélectionnez cette commande :

Show ip wccp service detail

Pour des options de configuration supplémentaires WCCP, telles que l'adressage de groupe utilisant la Multidiffusion ou la Sécurité supplémentaire WCCP, référez-vous à configurer des services de cache de Web utilisant le WCCP.

Commandes d'exposition et de debug IOS WCCP

  • service-nombre de show ip wccp - fournit le compte réorienté « par paquets totaux ». Ce compte est le nombre d'écoulements, ou des sessions, qui sont réorientées.
  • détail de service-nombre de show ip wccp - fournit le compte réorienté des « par paquets ». Le compte est le nombre d'écoulements, ou des sessions, qui sont réorientées.
  • détail de Web-cache de show ip wccp - fournit une indication de combien d'écoulements, plutôt que des paquets, utilisent la redirection L2.
  • clear ip wccp - remet à l'état initial le compteur pour les informations réorientées des « par paquets ».
  • vue de service-nombre de show ip wccp - affiche les périphériques WCCP qui font partie du groupe de service.
  • service de service-nombre de show ip wccp - affiche les informations parasites, les ports, et la priorité WCCP du service. Des services plus prioritaires sont frappés d'abord quand des plusieurs services sont configurés sur l'interface.
  • debug ip wccp events - dépanne l'état du protocole WCCP.
  • mettez au point les paquets d'ip wccp - passe en revue les transmissions entre les entités de traitement de paquets WCCP.

Quand vous utilisez le WCCP et l'expédition de matériel, quelques compteurs peuvent ne pas afficher comme prévu :

  • Si l'ACL WCCP est traité complètement dans le matériel, les compteurs WCCP peuvent ne pas afficher des comptes précis de paquet.
  • Si le WCCP utilise les ressources parasites information en affectation et en matériel de NetFlow, les compteurs WCCP peuvent refléter le nombre d'écoulements au lieu du nombre de paquets.

Commandes de NetFlow

Quand vous avez des configurations WCCP qui exigent l'utilisation des ressources en matériel de NetFlow, utilisez ces la commutation multicouche (MLS) et les commandes de Fabric Manager (FM) ainsi vous pouvez passer en revue le statut des ressources en NetFlow :

  • table-conflit de show mls netflow détaillé
  • show mls netflow ip sw-installed
  • vieillissement de show mls netflow
  • compte de show mls netflow ip dynamic
  • compte de show mls netflow ip
  • show mls ip
  • compteurs de show fm netflow

Défauts WCCP

Cette table des id et des résolutions de bogue Cisco prend en charge la recommandation générale d'utiliser la version du logiciel Cisco IOS 12.2(18)SXF7 ou plus tard pour le meilleur support du WCCP.

ID de débogage CiscoRésolu dans la version du logiciel Cisco IOSDétails
CSCsd2032712.2(18)SXF7Le WCCP pour le service 90 va en haut et en bas, et entraîne une perte de service WCCP. Ce problème se pose quand les services 81, 82, et 90 sont configurés. Les tracés de paquets indiquent que le routeur pourrait répondre aux messages de « Here_I_Am » du cache avec les messages de « I_See_You » qui contiennent une adresse IP incorrecte de destination.
CSCsa7778512.2(18)SXF6Une recharge pourrait se produire quand vous utilisez la redirection WCCP L2 et masquez le mode d'affectation avec un ACL standard géré par le système central pendant qu'un WCCP réorientent l'ACL.
CSCse6971312.2(18)SXF6Quand tous les moteurs de cache dans un groupe de service WCCP sont perdus, le trafic est traité en logiciel au lieu de commuter dans le matériel.
CSCsd2887012.2(18)SXF5Dans un WCCP réorientez la liste d'ACL, les as qui sont configurés avec le mot clé de journal ne sont pas programmés dans la table TCAM.
CSCsb6102112.2(18)SXF5L'utilisation du CPU élevé pourrait se produire sur une engine 720 de superviseur ou une engine 32 de superviseur quand la caractéristique d'usurpation d'adresse IP est configurée sur un moteur de cache et quand la redirection WCCP est configurée dans la direction de sortie. des paquets IP-charriés du moteur de cache, avec une destination du client ou du serveur, sont commutés en logiciel au lieu du matériel.

Comme contournement, utilisez le service d'ip wccp réorientent aux commandes pour les interfaces d'arrivée et sortantes.
CSCsb2197212.2(18)SXF2Le WCCP et le NDE étant configuré, vous pourriez voir de nombreux retours arrière provoqués par des erreurs de cadrage, et l'utilisation du processeur pourrait être inadmissiblement élevée.
CSCeh8508712.2(18)SXFQuand il y a utilisateur-configuré « refusez l'IP tout » dans le WCCP réorientent l'ACL et quand beaucoup de groupes de service WCCP sont entretenus, le trafic associé avec quelques groupes de service n'est pas réorienté aux Routeurs de la CE.
CSCeh5691612.2(18)SXFQuand un service WCCP est activé, quand l'affectation de masque est configurée comme méthode d'affectation, et quand cinq caches ou plus sont dans le groupe de service, les messages de gestion de protocole envoyés dans le cache peuvent déborder et entraîner la corruption de mémoire et la recharge.
CSCsb1874012.2(18)SXF et SXE6En mode basé sur GRE d'expédition, le WCCP utilise inutilement un cache de logiciel qui augmente l'utilisation du processeur MSFC.
CSCsb2677312.2(18)SXFUn ACL d'arrivée pourrait faire échouer la redirection WCCP avec la perte de tout le trafic redirigé.
CSCsa9083012.2(18)SXE2Le trafic d'entrée-réorienté par WCCP utilise la table de NetFlow pour la commutation de matériel quand le moteur de cache est configuré pour l'expédition GRE avec le mode d'affectation de masque. Quand la table de NetFlow est pleine, la redirection d'entrée WCCP échoue.
CSCec5542912.2(18)SXELa liste de groupe de service WCCP est analysée dans la commande dans laquelle des groupes de service sont créés, plutôt que par priorité. Si de plusieurs services dynamiques WCCP sont définis, trafiquez qu'apparie les critères de sélection pour plus d'un groupe de service n'est pas réorienté au groupe de service avec le plus prioritaire.
CSCuk5087812.2(18)SXE

Dans une release où l'ID de bogue Cisco CSCec55429 est résolu, après qu'un certain nombre de WCC des événements perdus » et « par cache trouvés » de « cache se soient produits pour tous les caches dans un groupe de service, ces événements peuvent se produire :

  • Les accès mémoire erratiques pourraient se produire.
  • L'ajout et la suppression des services WCCP pourraient échouer.
  • La commande de show ip wccp affiche le service WCCP, mais la sortie de la commande de service_number de show ip wccp n'affiche pas le service WCCP.
CSCsa6761112.2(18)SXELes paquets entrants de Commutation multiprotocole par étiquette (MPLS) qui quittent sur une interface non-MPLS (balise au chemin d'IP) sur laquelle une caractéristique de sortie est configurée (par exemple, ACL ou de sortie WCCP de sortie) ne pourraient pas avoir les caractéristiques de sortie appliquées. Ce problème se pose parce que la consultation d'ACL de sortie est sautée.
CSCeh1329212.2(18)SXD4La configuration de WCCPv2 sur une engine 720 de superviseur entraîne l'utilisation du CPU élevé.
CSCeb2894112.2(18)SXD1Le Traduction d'adresses de réseau (NAT) ne fonctionne pas avec le WCCP configuré.
CSCed9229012.2(17d)SXB2les paquets WCCP-réorientés qui n'ont aucune entrée de cache de Protocole ARP (Address Resolution Protocol) de prochain-saut sont commutés par processus pour générer une demande d'ARP. En raison de la redirection WCCP, cependant, aucune demande d'ARP n'est envoyée, le cache d'ARP n'est jamais rempli pour le prochain saut, et les paquets WCCP-réorientés ultérieurs continuent à être commutés par processus. 
CSCuk5982512.2(17d)SXF5 -Sup2 Whitney1.0 pour Sup720Cette version logicielle de Cisco IOS a ajouté le support matériel pour le trafic du retour L2. Le document RFC WCCP (RFC) spécifie le retour L2 comme capacité facultative pour la négociation entre le routeur et le cache. Jusqu'ici, le WCCP sur le logiciel de Cisco IOS n'a pas permis la négociation de cette capacité parce que le support de matériel requis est absent. Que le support est maintenant disponible, ainsi la négociation du retour L2 dans l'échange de protocole WCCP entre le routeur et cache peut être activé.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 116134