Services de mise en réseau d'applications : Cisco LocalDirector de la gamme 400

Résolution des problèmes de paquets non traduits devant LocalDirector

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


Cisco a annoncé l' interruption de vente pour Cisco LocalDirector. Le pour en savoir plus, se rapportent aux notices de fin de vie et de fin de commercialisation de gamme 400 de LocalDirector et à des bulletins de produit.


Contenu


Introduction

Ce document fournit des informations sur la façon dont dépanner les paquets non traduits devant le LocalDirector.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

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.

Conventions

Pour plus d'informations sur les conventions de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Symptômes

Des paquets peuvent être trouvés devant le LocalDirector avec l'adresse IP source de la vraie adresse IP des serveurs au lieu de l'adresse virtuelle. Ces paquets appartiennent aux sessions ouvertes par les clients externes aux adresses virtuelles du LocalDirector, et ils sont habituellement des paquets appartenant à un ordre normal d'arrêt de connexion TCP (FIN) ou de remise de connexion (RST). Puisque ces paquets sont juste une partie d'une séance de clôture, aucun problème de connectivité n'est expérimenté.

Ceci deviennent plus visible dans les configurations où les serveurs utilisent une adresse IP privée, le virtuel utilise une annonce publique, et la passerelle est un Pare-feu et pas un routeur. Dans ce cas, un message pourrait sont enregistré par le Pare-feu informant qu'une adresse IP source inattendue a été reçue du réseau interne.

Architecture de LocalDirector

Afin de comprendre les raisons pour ce comportement, une brève description de l'architecture du LocalDirector est fournie dans cette section.

Quand un client ouvre une connexion à une adresse virtuelle, un identifiant pour l'écoulement est entré dans la table de traduction. Ces entrées contiennent toutes les informations sur l'écoulement afin de le dépister et faire les manipulations nécessaires dans les paquets suivants. Ces entrées ont un cycle de vie et quand la session TCP s'est terminée, elles sont normalement retirées pour éviter le gaspillage de ressources en mémoire.

Dans la pratique, le LocalDirector continue à regarder le trafic de session et quand il voit les paquets spécifiques de fermeture de session, il retire les entrées de la table de traduction.

Le LocalDirector retire les entrées de traduction quand il l'un ou l'autre voit un arrêt standard de connexion (FIN) ou une remise de connexion (RST).

Dans quelques scénarios, selon la topologie mise en application, les délais réseau, les piles mises en application de TCP, et les applications, retransmission de quelques paquets en retard d'une séance de clôture arrivent au LocalDirector quand l'entrée dans la table de traduction a été déjà retirée. Dans ce cas, le LocalDirector jette un pont sur ces paquets non traduits, entraînant les symptômes décrits au début de ce document.

Une analyse approfondie de cette situation exige toujours qu'un tracé de renifleur simultané soit pris sur l'avant et au dos du LocalDirector. Par arrière suivant une session TCP qui a fini avec un paquet non traduit, il est possible de voir clairement la cause de ce comportement.

Une fois la cause est déterminée, l'étape suivante est de considérer, que ceci entraîne une question ou pas. Très peu de paquets seront vus réellement dans cet état, et ils ne posent pas réellement un problème au delà de la génération possible d'un paquet de remise de nouveau à l'expéditeur. Le le pire des cas peut être les messages d'avertissement connectés par le Pare-feu.

Solutions

Si cette question affecte votre réseau, ce sont les solutions possibles :

  • Commande de retard de question.

  • Sécurisez le LocalDirector en émettant la commande sécurisée.

  • Des Listes d'accès (ACLs) pourraient être appliquées sur la passerelle.

La commande de retard fait maintenir le le LocalDirector l'entrée de traduction pendant cinq minutes supplémentaires (cette valeur ne peut pas être changée) dans la table de traduction après qu'un arrêt standard de connexion TCP ou une remise de connexion aient été vus. Ajouter cette commande permet au LocalDirector pour traduire correctement les paquets en retard, mais peut consommer les ressources excessives en LocalDirector (particulièrement dans les environnements très chargés). Ceci se produit en raison du temps accru que l'entrée de traduction doit être maintenue dans la mémoire.

La commande sécurisée fait bloquer le LocalDirector tout le trafic allant par le LocalDirector qui n'ont pas une entrée dans la table de traduction. Ceci doit être considéré au cas où les serveurs internes devraient entrer en contact avec des périphériques au delà du LocalDirector dans le réseau local. Un exemple typique pourrait être un serveur DNS utilisé par les serveurs internes pour la consultation inverse d'une adresse IP de client demandant le contenu.

Si la passerelle est un routeur et pas un Pare-feu, un ACL pourrait être appliqué là-dessus pour bloquer les paquets non traduits.

Pour plus d'informations sur le retard et les commandes sécurisées, référez-vous aux descriptions de commande de LocalDirector pour la version que vous utilisez.

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.


Informations connexes


Document ID: 12434