Session WCCP vers le routeur/commutateur actif, mais la navigation n'a pas lieu en raison de problèmes de route

Question :

Session WCCP vers le routeur/commutateur actif, mais la navigation n'a pas lieu en raison de problèmes de route

Environnement :

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

Symptômes :

La session WCCP est active et fonctionne, mais la navigation ne fonctionne pas.

Dans certaines circonstances, le dispositif de sécurité Web Cisco peut communiquer avec le routeur, mais le trafic client peut ne pas passer. La session WCCP est active, mais aucune navigation n'est en cours.

La configuration WCCP sur le commutateur Catalyst est minimale (la liste de redirection n'est pas liée à cette discussion, mais est reproduite ici par souci d'exhaustivité) :

ip wccp 91 redirect-list 130 group-list 30

interface Vlan20
description client vlan 20
ip address 192.168.20.1 255.255.255.0
ip wccp 91 redirect in

access-list 30 permit 10.66.71.17
access-list 130 permit ip any host 192.168.20.103 log
access-list 130 permit ip host 192.168.20.103 any log

Nous verrions que WCCP est actif :

Switch#sh ip wccp 91 d
Informations sur le client WCCP :

        ID client WCCP : 10.66.71.17
        Version du protocole : 2.0
        État : utilisable       
        Redirection : L2
        Retour de paquet : L2
        Paquets redirigés : 0
        Heure de connexion : 00:12:49
        Affectation : MASQUE

Mais la navigation pourrait échouer.

Le problème réside dans la configuration de la route sur le dispositif de sécurité Web Cisco. Par exemple, l'appliance de sécurité Web Cisco ne dispose peut-être pas d'une route pour revenir au VLAN 20. La configuration de la route qui ne fonctionne pas est la suivante :

Le problème est généralement observé si une seule interface (M1) est utilisée pour le dispositif de sécurité Web Cisco pour la gestion et le trafic de données. Dans l'exemple ci-dessus, nous avons une route vers VLAN 30 via la deuxième entrée et une route vers le périphérique WCCP via la troisième entrée et une route par défaut vers 10.66.71.1 pour tous les autres réseaux. Cependant, si 10.66.71.1 est la passerelle vers Internet mais ne sait pas comment router vers 192.168.20.0/24, le routage échouera et les navigateurs clients ne pourront pas naviguer.

Un test ping simple montrerait si nous avons une route vers le client.

s650a.lab (SERVICE)> ping 192.168.20.103

Appuyez sur Ctrl-C pour arrêter.
PING 192.168.20.103 (192.168.20.103) : 56 octets de données
^C— 192.168.20.103 statistiques ping —
17 paquets transmis, 0 paquet reçu, perte de paquets de 100 %

La solution à ce problème consiste à ajouter une route sur le dispositif de sécurité Web Cisco aux VLAN clients.  Pour ce faire, vous pouvez :

WebUI > Réseau > Route > Add Route 

Après avoir ajouté ceci, les requêtes ping doivent circuler de l'appliance de sécurité Web Cisco vers le client et la navigation doit se faire sur les clients dans le VLAN 20 (hôte 192.168.20.103 dans cet exemple).

s650a.lab (SERVICE)> ping 192.168.20.103

Appuyez sur Ctrl-C pour arrêter.PING 192.168.20.103 (192.168.20.103) : 56 octets de données
64 octets de 192.168.20.103 : icmp_seq=0 ttl=127 time=0,835 ms
64 octets de 192.168.20.103 : icmp_seq=1 ttl=127 time=0,343 ms

^C— 192.168.20.103 statistiques ping —
2 paquets transmis, 2 paquets reçus, perte de paquets de 0 %
aller-retour min/avg/max/stddev = 0,343/0,589/0,835/0,246 ms

Notez qu'il est interdit de répéter que c'est l'une des raisons pour lesquelles la navigation peut échouer. Il pourrait y avoir d'autres raisons pour lesquelles WCCP serait activé, mais la navigation ne fonctionnerait pas, mais c'est un des problèmes les plus courants.