Session WCCP au routeur/au commutateur, mais parcourant l'événement devant conduire des questions

Question :

Session WCCP au routeur/au commutateur, mais parcourant l'événement devant conduire des questions

Environnement :

Appliance de sécurité Web de Cisco
Commutateur de Catalyst, routeur, ASA

Symptômes :

La session WCCP est en hausse et fonctionnante mais le furetage ne fonctionne pas.

Dans certaines circonstances, l'appliance de sécurité Web de Cisco peut parler au routeur mais le trafic de client ne pourrait pas passer. Nous verrions que session WCCP est mais aucun furetage ne se produit toujours.

La configuration WCCP sur le commutateur de Catalyst est minimale (la réorienter-liste n'est pas appropriée à cette discussion mais n'est pas reproduite ici dans l'intérêt de l'exhaustivité) :

groupe-liste 30 de la réorienter-liste 130 de l'ip wccp 91

interface Vlan20
VLAN 20 de client de description
IP address 192.168.20.1 255.255.255.0
l'ip wccp 91 réorientent dedans

autorisation 10.66.71.17 de la liste d'accès 30
IP d'autorisation de la liste d'accès 130 tout log de 192.168.20.103 d'hôte
l'hôte 192.168.20.103 d'IP d'autorisation de la liste d'accès 130 se en connectent

Nous verrions que le WCCP est :

Ip wccp 91 d de Switch#sh
Les informations de client WCCP :

        ID de client WCCP :          10.66.71.17
        Version de Protocol :        2.0
        État :                   Utilisable       
        Redirection :             L2
        Retour de paquet :           L2
        Paquets réorientés :      0
        Temps de connexion :            00:12:49
        Affectation :              MASQUE

Mais le furetage a pu pour se produire.

Le problème se trouve avec la configuration de route sur l'appliance de sécurité Web de Cisco. Par exemple, l'appliance de sécurité Web de Cisco ne pourrait pas avoir une artère à revenir au VLAN 20. La configuration de route non-travaillante est comme suit :

Le problème est habituellement vu si seulement une interface (M1) est utilisée pour l'appliance de sécurité Web de Cisco pour la Gestion et le trafic de données. Dans l'exemple ci-dessus, nous avons l'artère au VLAN 30 par la deuxième entrée et la conduisons au périphérique WCCP par la troisième entrée et à un default route à 10.66.71.1 pour tous autres réseaux. Cependant si 10.66.71.1 est la passerelle à l'Internet mais ne sait pas la façon conduire à 192.168.20.0/24 conduisant alors échouerait et les navigateurs de client ne pourront pas parcourir.

Un test de ping simple afficherait si nous avons une route de retour vers le client.

s650a.lab (SERVICE) > ping 192.168.20.103

Presse CTRL-C à arrêter.
PING 192.168.20.103 (192.168.20.103) : 56 octets de données
^C------ statistiques de ping de 192.168.20.103 ------
17 paquets transmis, paquets 0 reçus, perte de paquets de 100%

La solution au problème est d'ajouter dans une artère sur l'appliance de sécurité Web de Cisco de nouveau au client VLAN.  Ceci peut être fait par :

WebUI > réseau > artère > ajoutent l'artère 

Après avoir ajouté ceci, les pings devraient découler de l'appliance de sécurité Web de Cisco au client et nous devrions voir l'événement de furetage sur les clients dans VLAN 20 (hôte 192.168.20.103 dans cet exemple).

s650a.lab (SERVICE) > ping 192.168.20.103

Presse CTRL-C à stop.PING 192.168.20.103 (192.168.20.103) : 56 octets de données
64 octets de 192.168.20.103 : ms icmp_seq=0 ttl=127 time=0.835
64 octets de 192.168.20.103 : ms icmp_seq=1 ttl=127 time=0.343

^C------ statistiques de ping de 192.168.20.103 ------
2 paquets transmis, 2 paquets reçus, perte de paquets de 0%
min/moy/max aller-retour/stddev = 0.343/0.589/0.835/0.246 ms

Veuillez noter qu'il découvre répéter ce ceci est un de la raison pour laquelle le furetage pourrait échouer. Il pourrait y avoir d'autres raisons pour lesquelles le WCCP serait mais le furetage ne fonctionnerait pas mais c'est l'un de plus de problèmes courants.