Commutation LAN : Virtual LAN/VLAN Trunking Protocol (VLAN/VTP)

Causes courantes de connexions IntraVLAN et InterVLAN lentes dans les réseaux campus commutés

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (7 octobre 2015) | Commentaires


Contenu


Introduction

Ce document aborde les la plupart des questions de ½ du ¿  de commonï qui peuvent contribuer au ½ du ¿  de la lenteur. ï de réseau que le document classifie des symptômes de lenteur de réseau commun, et aux approches d'ensembles au diagnostic et à la résolution de problème.

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.

Conventions

Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.

Causes classiques de Connectivité lente d'IntraVLAN et d'InterVLAN

Les symptômes de la Connectivité lente sur un VLAN peuvent sont provoqué par par de plusieurs facteurs sur différentes couches réseau. Généralement la question de vitesse du réseau peut se produire sur un niveau plus bas, mais on peut observer des symptômes sur un niveau supérieur pendant que le problème se masque en vertu de la condition « VLAN lent ». Pour clarifier, ce document définit les nouveaux termes suivants : « domaine de collision lent », « ralentissez le domaine d'émission » (en d'autres termes, VLAN lent), et « l'expédition lent d'interVLAN ». Ceux-ci sont définis dans les catégories de la section trois de causes, ci-dessous.

Dans le scénario suivant (illustré dans le schéma de réseau ci-dessous), il y a un commutateur de la couche 3 (L3) exécutant le routage d'interVLAN entre le serveur et le client VLAN. Dans ce scénario de panne, un serveur est connecté à un commutateur, et le mode duplex du port est bidirectionnel-alterné sur le côté serveur et bidirectionnel simultané configurés du côté de commutateur. Cette mauvaise configuration a comme conséquence une perte de paquets et une lenteur, avec la perte de paquets accrue quand des débits de trafic plus supérieurs se produisent sur le lien où le serveur est connecté. Pour les clients qui communiquent avec ce serveur, le problème ressemble à l'expédition lent d'interVLAN parce qu'ils n'ont pas un problème communiquant à d'autres périphériques ou clients sur le même VLAN. Le problème se pose seulement en communiquant au serveur sur un VLAN différent. Ainsi, le problème s'est posé sur un domaine de collision unique, mais est vu en tant qu'expédition lent d'interVLAN.

slow_int_vlan_connect-1.gif

Trois catégories de causes

Les causes de la lenteur peuvent être divisées en trois catégories, comme suit :

Connectivité lente de domaine de collision

Le domaine de collision est défini comme périphériques connectés configurés dans une configuration de port en semi-duplex, connectée entre eux ou un hub. Si un périphérique est connecté à un port de commutateur et le mode bidirectionnel simultané est configuré, une telle connexion point-à-point est non-collisionnelle. La lenteur sur un tel segment peut encore se produire pour différentes raisons.

Ralentissez la Connectivité de domaine d'émission (le VLAN lent)

La Connectivité lente de domaine d'émission se produit quand le VLAN entier (c'est-à-dire, tous les périphériques sur le même VLAN) éprouve la lenteur.

Connectivité lente d'InterVLAN (expédition lent entre les VLAN)

La Connectivité lente d'interVLAN (expédition lent entre les VLAN) se produit quand il n'y a aucune lenteur sur les gens du pays VLAN, mais le trafic doit être expédiée à un VLAN alternatif, et elle n'est pas expédiée au débit prévu.

Causes pour la lenteur de réseau

Perte de paquets

Dans la plupart des cas, un réseau est considéré lent quand les protocoles de couche plus élevée (applications) ont besoin de l'heure étendue de se terminer une exécution qui exécute typiquement plus rapide. Cette lenteur est provoqué par par la perte de quelques paquets sur le réseau, qui fait chronométrer et initier des protocoles de plus haut niveau comme le TCP ou les applications la retransmission.

Questions d'expédition de matériel

Un autre type de lenteur, étant provoqué par l'équipement réseau, expédiant (si couche 2 [L2] ou L3) est exécuté lentement. C'est dû à une déviation d'exécution et de commutation (conçues) normales pour ralentir l'expédition de chemin. Un exemple de ceci est quand la commutation multicouche (MLS) sur de switchï du ¿  de ½ les paquets L3 en avant entre les VLAN dans le matériel, mais en raison de la mauvaise configuration, MLS ne fonctionne pas correctement et la transmission est faite par le routeur en logiciel (qui relâche le taux à terme d'interVLAN de manière significative).

Dépannez la cause

Dépannez les questions de domaine de collision

Ainsi si votre VLAN semble être lent, isolez d'abord les problèmes de domaine de collision. Vous devez établir si seulement les utilisateurs sur le même domaine de collision rencontrent des problèmes de Connectivité, ou s'il se produit sur des plusieurs domaines. Pour faire ceci, faire un transfert des données entre les PC d'utilisateur sur le même domaine de collision, et comparer cette représentation à la représentation d'un autre domaine de collision, ou à sa représentation prévue.

Si les problèmes se posent seulement sur ce domaine de collision, et la représentation d'autres domaines de collision dans le même VLAN est normale, alors regardez les compteurs de port sur le commutateur pour déterminer quels problèmes ce segment peut éprouver. Très probablement, la cause est simple, comme un conflit du mode bidirectionnel. Un autre, moins de cause de ½ du ¿  de frequentï est un segment surchargé ou oversubscribed. Pour plus d'informations sur dépanner un problème simple de segment, référez-vous au document configurant et dépannage de l'Automatique-négociation de half/full duplex des Ethernets 10/100/1000Mb.

Si les utilisateurs sur différents domaines de collision (mais dans le même VLAN) ont les mêmes problèmes de performance, il peut encore sont provoqué par par un conflit du mode bidirectionnel sur un ou plusieurs segments d'Ethernets entre la source et la destination. Le scénario suivant se produit souvent : un commutateur est configuré manuellement pour avoir bidirectionnel simultané sur tous les ports dans le VLAN (la valeur par défaut est « automatique »), alors que les utilisateurs (networks interface cards [NIC]) connectés aux ports exécutent une procédure de négociation automatique. Ceci a comme conséquence le conflit du mode bidirectionnel sur tous les ports et, en conséquence, la mauvaise représentation sur chaque port (domaine de collision). Ainsi, bien qu'il soit évident comme si le VLAN entier (domaine d'émission) a un problème de performances, il est encore classé par catégorie comme conflit du mode bidirectionnel, pour le domaine de collision de chaque port.

Un autre cas à considérer est un problème de performances particulier NIC. Si un NIC avec un problème de performances est connecté à un segment partagé, alors il peut être évident qu'un segment entier éprouve la lenteur, particulièrement si le NIC appartient à un serveur qui sert également d'autres segments ou VLAN. Maintenez ce cas dans l'esprit parce qu'il peut vous tromper pendant que vous dépannez. De nouveau, la meilleure manière de rétrécir vers le bas cette question est d'exécuter un transfert des données entre deux hôtes sur le même segment (où le NIC avec le problème supposé est connecté), ou si seulement le NIC est sur ce port, l'isolation n'est pas facile, ainsi essayez un NIC différent dans cet hôte, ou essai connectant l'hôte suspecté sur un port distinct, en assurant la configuration correcte du port et du NIC.

Si le problème existe toujours, essayez dépanner le port de commutateur. Référez-vous au port de commutateur de dépannage de document et reliez les problèmes.

Le cas le plus grave est quand certains ou tous les NIC incompatibles sont connectés à un commutateur de Cisco. Dans ce cas, il s'avère que le commutateur a des problèmes de performance. Pour vérifier la compatibilité des NIC avec des Commutateurs de Cisco, référez-vous aux commutateurs Cisco Catalyst de dépannage de document aux problèmes de compatibilité NIC.

Vous devez distinguer les deux premiers cas (lenteur de domaine de collision de dépannage et lenteur VLAN) parce que ces deux causes impliquent différents domaines. Avec la lenteur de domaine de collision, le problème se trouve en dehors du commutateur (ou au bord du commutateur, sur un port de commutateur) ou externe au commutateur. Il se peut que seul le segment ait des problèmes (par exemple, un segment oversubscribed, dépassant la longueur de segment, les problèmes physiques sur le segment, ou les problèmes de hub/répéteur). Dans le cas de la lenteur VLAN, le problème se trouve très probablement à l'intérieur du commutateur (ou des plusieurs commutateurs). Si vous diagnostiquez le problème inexactement, vous pouvez perdre le temps recherchant le problème dans le mauvais endroit.

Ainsi, après que vous ayez diagnostiqué une caisse, vérifiez les éléments répertoriés ci-dessous.

Dans le cas d'un segment partagé :

  • déterminez si le segment est surchargé ou oversubscribed

  • déterminez si le segment est sain (comprenant si la longueur des câbles est correcte, si l'atténuation est dans la norme, et s'il y a des dommages physiques du support)

  • déterminez si le port de réseau et tous NIC connectés à un segment ont les configurations compatibles

  • déterminez si le NIC exécute bien (et exécute le dernier gestionnaire)

  • déterminez si le port de réseau continue à afficher des erreurs croissantes

  • déterminez si le port de réseau est surchargé (particulièrement si c'est un port de serveur)

Dans le cas d'un segment partagé point par point, ou du segment (bidirectionnel simultané) non-collisionnel :

  • déterminez le port et la configuration NIC-compatible

  • déterminez les santés du segment

  • déterminez les santés du NIC

  • recherchez les erreurs de port ou le surabonnement de réseau

Dépannez IntraVLAN lent (le domaine d'émission)

Après avoir vérifié il n'y a aucune question de conflit du mode bidirectionnel ou de domaine de collision comme expliqué dans la section ci-dessus, vous pouvez maintenant dépanner la lenteur d'IntraVLAN. L'étape suivante en isolant l'emplacement de la lenteur est d'effectuer un transfert des données entre les hôtes sur le même VLAN (mais sur différents ports ; c'est-à-dire, sur différents domaines de collision), et comparez la représentation aux mêmes tests dans des VLAN alternatifs.

Ce qui suit peut entraîner des VLAN lents :

les causes 1These trois de la Connectivité lente d'intraVLAN sont hors de portée de ce document, et peuvent exiger le dépannage par un ingénieur de support technique de Cisco. Après avoir éliminé les cinq premières causes possibles répertoriées ci-dessus, vous pouvez devoir ouvrir une demande de service avec le support technique de Cisco.

Boucle du trafic

Une boucle du trafic est la plupart de cause classique d'un VLAN lent. Avec une boucle, vous devriez voir d'autres symptômes qui indiquent que vous éprouvez une boucle. Pour les dépannages des boucles du Protocole Spanning Tree (STP), se rapportent aux problèmes et aux considérations de conception associée de Protocole Spanning Tree de document. Bien que les Commutateurs puissants (comme Cisco Catalyst 6500/6000) avec les fonds de panier gigabit-capables puissent manipuler le quelque (STP) fassent une boucle sans compromettre la représentation de la CPU de Gestion, les paquets faits une boucle puissent faire déborder des tampons d'entrée sur des NIC et recevoir/transmettez les mémoires tampons (Rx/Tx) sur les Commutateurs, entraînant la représentation lente en se connectant à d'autres périphériques.

Un autre exemple de la boucle est un EtherChannel asymétriquement configuré, suivant les indications du scénario suivant :

slow_int_vlan_connect-2.gif

Dans cet exemple, les ports 1/1 et 1/2 sont dans le canal, mais les ports 2/1 et 2/2 ne sont pas.

Le commutateur 1 a un canal configuré (canal obligatoire), et le ½ du ¿  du commutateur 2ï n'a aucune configuration de canal pour les ports correspondants. Si le trafic propagé (mcast/BCAST/unicast inconnu) découle du commutateur 1 vers Comm2, le fait une boucle Comm2 de nouveau dans le canal. Ce n'est pas une boucle complète, puisque le trafic n'est pas fait une boucle continuellement, mais est seulement reflété une fois. Il est un demi- de toute la boucle. Avoir deux telles mauvaises configurations peut créer une boucle complète, suivant les indications de l'exemple ci-dessous.

slow_int_vlan_connect-3.gif

Le risque de avoir une telle mauvaise configuration est que des adresses MAC sont apprises sur les ports incorrects pendant que le trafic est inexactement commuté, qui entraîne la perte de paquets. Considérez, par exemple, un routeur avec le Protocole HSRP (Hot Standby Router Protocol) actif qui est connecté pour commuter 1 (suivant les indications du diagramme ci-dessus). Après que le routeur annonce des paquets, son MAC est fait une boucle - arrière par Comm2 et appris outre du canal par le commutateur 1, jusqu'à ce qu'un paquet monodiffusion soit envoyé du routeur de nouveau.

VLAN surchargé ou Oversubscribed

Avis s'il y a des étranglements (segments oversubscribed) n'importe où sur vos VLAN et les localise. Le premier signe que votre VLAN est surchargé est si les mémoires tampons de Rx ou de Tx sur un port sont oversubscribed. Si vous voyez des outdiscards ou des indiscards sur quelques ports, vérifiez pour voir si ces ports sont surchargés. (Une augmentation des indiscards indique non seulement une pleine mémoire tampon de Rx.) En SYSTÈME D'EXPLOITATION de Catalyst (CatOS), les commandes utiles d'émettre sont modèle de show mac/port ou show top [N]. En logiciel de ½ du ¿  de Cisco IOSï (indigène), vous pouvez émettre les compteurs des interfaces slot#/port# d'exposition que les erreurs commandent de voir des écarts. Le scénario surchargé ou oversubscribed VLAN et le scénario de boucle du trafic s'accompagnent souvent, mais ils peuvent également exister séparément.

Le plus souvent, la surcharge se produit sur les ports de circuit principal quand la bande passante agrégée du trafic est sous-estimée. La meilleure manière de fonctionner autour de ce problème est de configurer un EtherChannel entre les périphériques pour lesquels les ports sont embouteillés. Si le segment de réseau est déjà un canal, ajoutez plus de ports dans un groupe de canaux pour augmenter la capacité de canal.

Rendez-vous également compte de la question de polarisation de Technologie Cisco Express Forwarding (CEF). Ce problème se produit sur les réseaux dans lesquels le trafic est chargement-équilibré par des Routeurs, mais en raison de l'uniformité d'algorithme de Cisco Express Forwarding, tout le trafic est polarisé et, sur le prochain saut, il n'est pas chargement-équilibré. Ce problème ne se pose pas souvent, cependant, parce qu'il exige une certaine topologie avec les liens L3 chargement-équilibrés. Pour plus d'informations sur Cisco Express Forwarding et l'Équilibrage de charge, voyez pour dépanner le Routage IP d'Unicast impliquant le CEF sur des Commutateurs de gamme Catalyst 6500/6000 d'un logiciel système de CatOS de Supervisor Engine 2 et d'exécution.

Une autre cause pour le VLAN surchargé est un problème asymétrique de routage. Ce type de configuration peut également entraîner un niveau de trafic excessivement à hauteur inondant vos VLAN. Le pour en savoir plus, se rapportent à la cause 1 : Section de routage asymétrique de l'inondation d'Unicast de document dans les réseaux campus commutés.

Parfois un étranglement peut être un périphérique de réseau lui-même. Si vous essai, par exemple, pour pomper le trafic 4-gigabit bien que le commutateur avec un fond de panier 3-gigabit, vous finissent par avec une perte excessive du trafic. La compréhension de l'architecture de commutateur réseau est hors de portée de ce document ; cependant, quand vu la capacité d'un commutateur réseau, attention de paiement aux aspects suivants :

  • capacité du fond de panier

  • tête-de-line bloquant des problèmes

  • blocage et architecture non groupante de commutateur/port

Encombrement sur le chemin intrabande de commutateur

L'encombrement sur le chemin intrabande de commutateur peut avoir comme conséquence une boucle de spanning tree ou d'autres types d'instabilité sur le réseau. Le port intrabande sur n'importe quel commutateur de Cisco est un port virtuel qui fournit l'interface pour le trafic d'administration (le trafic tel que Cisco Discovery Protocol et protocole d'agrégation de ports [PAgP]) au processeur de Gestion. Le port intrabande est considéré virtuel parce que, en quelques architectures, l'utilisateur ne peut pas le voir, et les fonctions intrabandes sont combinées avec l'exécution de portuaire normale. Par exemple, l'interface SC0 sur le Catalyst 4000, des Commutateurs de gammes Catalyst 5000 et Catalyst 6500/6000 (exécutant CatOS) est un sous-ensemble du port intrabande. L'interface SC0 fournit seulement une pile IP pour le processeur de Gestion dans le VLAN configuré, alors que le port intrabande permet d'accéder au processeur de Gestion pour les Bridges Protocol Data Unit (BPDU) dans des VLAN configurés l'uns des et pour beaucoup d'autres protocoles de gestion (tels que le Cisco Discovery Protocol, le protocole de gestion de groupes Internet (IGMP) [IGMP], le protocole de gestion de groupes Cisco, et la jonction dynamique Protocol [DTP]).

Si le port intrabande obtient surchargé (en raison d'un trafic misconfigured d'application ou d'utilisateur), il peut avoir comme conséquence l'instabilité de tous les protocoles pour lesquels la stabilité de ½ du ¿  de stateï de protocole est basée sur les messages réguliers ou de « hellos » reçus. Cet état peut avoir comme conséquence les boucles provisoires, relie le lien instable, et d'autres questions, entraînant ce type de lenteur.

Il est difficile d'entraîner l'encombrement du port intrabande sur le commutateur, bien que les attaques avec malveillance formées du déni de service (DOS) puissent réussir. Il n'y a aucune manière au rate-limit ou réduit le trafic sur le port intrabande. Une solution exige l'intervention et l'enquête d'administrateur de commutateur. Les ports intrabandes ont généralement une tolérance élevée pour l'encombrement. Rarement fait la défaillance intrabande de port ou l'est bloqué dans la direction de Rx ou de Tx. Ceci signifierait la panne grave de matériel et affecterait le commutateur entier. Cette condition est difficile à reconnaître et est habituellement diagnostiquée par des ingénieurs de support technique de Cisco. Les symptômes sont qu'un commutateur soudainement devient « sourd » et cesse de voir le trafic de contrôle de telles mises à jour de voisin de Cisco Discovery Protocol de ½ du ¿  d'asïÂ. Ceci indique un problème intrabande de Rx. (Si, cependant, juste un voisin de Cisco Discovery Protocol est vu, vous pouvez être sûr qu'intrabande fonctionne.) Également, si tous les commutateurs connectés perdent le Cisco Discovery Protocol d'un commutateur simple (aussi bien que de tous autres protocoles de gestion), il indique des problèmes de Tx de l'interface intrabande de ce commutateur.

Utilisation du CPU élevé de processeur de gestion de la commutation

Si un chemin intrabande est surchargé, il peut faire éprouver un commutateur des états élevés CPU ; et, comme la CPU traite le tout ce que le trafic inutile, la situation empire. Si l'utilisation du CPU élevé est provoqué par par un chemin intrabande surchargé ou une question alternative, elle peut affecter des protocoles de gestion comme décrit dans l'encombrement sur la section intrabande de chemin de commutateur, en haut.

Considérez comme étant généralement la CPU de Gestion un point vulnérable de n'importe quel commutateur. Un commutateur correctement configuré réduit le risque de problèmes provoqués par l'utilisation du CPU élevé.

L'architecture du Supervisor Engine I et d'II des Commutateurs de gamme Catalyst 4000 est conçue tels que la CPU de Gestion est impliquée au-dessus dans la commutation. Maintenez dans l'esprit ce qui suit :

  • La CPU programme une matrice de commutateur toutes les fois qu'un nouveau chemin (le Supervisor Engine I et II sont chemin en fonction) écrit le commutateur. Si un port intrabande est surchargé, il cause n'importe quel nouveau chemin d'être lâché. Ceci a comme conséquence le paquet perdu (écart silent) et la lenteur dans les protocoles de couche plus élevée quand le trafic est commuté entre les ports. (Référez-vous à l'encombrement de section sur le chemin intrabande de commutateur, en haut.)

  • Puisque la CPU exécute partiellement la commutation dans le Supervisor Engine I et II, les états élevés CPU peuvent affecter les capacités de commutation du Catalyst 4000. L'utilisation du CPU élevé sur le Supervisor Engine I et II peuvent sont provoqué par par la commutation au-dessus elle-même.

Les engines de superviseur II+, III et IV de la gamme Catalyst 4500/4000 sont assez trafic-tolérantes, apprentissage d'adresse MAC de ½ du ¿  de butï dans le superviseur articulé autour d'un logiciel de Cisco IOS que l'engine est encore faite complètement dans le logiciel (par la CPU de Gestion) ; il y a une occasion que l'utilisation du CPU élevé peut affecter ce processus et entraîner la lenteur. Comme avec l'Engine I et II de ½ du ¿  de SupervisorïÂ, l'apprentissage d'adresse MAC massif ou réapprendre peut entraîner l'utilisation du CPU élevé sur les engines de superviseur II+, III et IV.

La CPU est impliquée dans le MAC apprenant des Commutateurs dans de Catalyst gamme 3500XL et 2900XL aussi bien, ainsi un processus qui des résultats dans la performance du CPU réapprenante d'affects d'adresse rapide.

En outre, le processus d'apprentissage d'adresse MAC (même si il est complètement mis en application dans le matériel) est un processus relativement lent, comparé à un procédé de commutation. S'il y a continuellement un haut débit de l'adresse MAC réapprenant, alors la cause doit être trouvée et éliminée. Une boucle de spanning tree sur le réseau peut entraîner ce type de réapprendre d'adresse MAC. Réapprendre d'adresse MAC (ou le lien instable d'adresse MAC) peut sont provoqué par également par les tiers Commutateurs qui implémentent des VLAN basés sur port, ainsi il signifie que les adresses MAC ne sont pas obtenir associé avec une balise VLAN. Ce genre de commutateur, une fois connecté à Cisco commute dans certaines configurations, peut avoir comme conséquence le MAC coulant entre les VLAN. Consécutivement, ceci peut mener à un haut débit de l'adresse MAC réapprenant et peut dégrader l'interprétation.

Erreurs d'entrée sur un commutateur cut-through

La propagation de paquet d'erreurs d'entrée de cut-through est rapportée pour ralentir la Connectivité de domaine de collision, mais parce que les paquets d'erreurs sont transférés vers un autre segment, le problème semble commuter entre les segments. Les commutateurs cut-through (tels que les commutateurs-routeur Campus de gamme Catalyst 8500 (CSRs) et le module de commutation 2948G-L3 ou L3 de Catalyst pour la gamme Catalyst 4000) commencent le paquet/commutation de trame dès que le commutateur aura assez d'informations d'indiquer l'en-tête L2/L3 du paquet pour expédier le paquet à sa destination port ou ports. Ainsi, alors que le paquet est commuté entre le d'entrée et les ports de sortie, le début du paquet est déjà expédié hors du port de sortie, alors que le reste du paquet est toujours en train d'être reçu par le port d'entrée. Que se produit si le segment d'entrée n'est pas sain et génère une erreur de contrôle de redondance cyclique (CRC) ou une trame incomplète ? Le commutateur identifie ceci seulement quand il reçoit l'extrémité de la trame et, à ce moment-là, la majeure partie de la trame est transférée hors du port de sortie. Puisqu'il ne semble aucun raisonnable de transférer le reste de la trame erronée, le repos est abandonné, le port de sortie incrémente l'erreur de « underrun », et le port d'entrée incrémente le compteur d'erreurs correspondant. Si les plusieurs ports d'entrée sont malsains et leur serveur réside sur le port de sortie, il s'avère que le segment du serveur a le problème, quoiqu'il ne soit pas.

Pour des Commutateurs du cut-through L3, observez pour des underrruns et, quand vous les voyez, vérifiez tous les ports d'entrée pour des erreurs.

Mauvaise configuration de matériel ou logiciel

La mauvaise configuration peut rendre un VLAN lent. Ces effets négatifs peuvent résulter d'un VLAN étant oversubscribed ou surchargé, mais le plus souvent, ils résultent d'une mauvaise conception ou des configurations négligées. Par exemple, un segment (VLAN) peut être facilement accablé par le trafic de multidiffusion (par exemple, vidéo ou flux audio) si le trafic de multidiffusion contraignant des techniques ne sont pas correctement configurés sur ce VLAN. Un tel trafic de multidiffusion peut affecter le transfert des données, entraînant la perte de paquets sur un VLAN entier pour tous les utilisateurs (et inondant les segments des utilisateurs qui n'ont pas eu l'intention de recevoir les flots de Multidiffusion).

Erreurs et problèmes matériels de programmation

Il est difficile l'identifier des erreurs et des problèmes matériels de programmation parce qu'elles entraînent la déviation, il est difficile de dépanner que. Si vous croyez que le problème est provoqué par par une erreur ou un problème matériel de programmation, contactez les ingénieurs de support technique de Cisco pour les faire étudier le problème.

Dépannez la Connectivité lente d'InterVLAN

Avant les dépannages de la Connectivité lente d'interVLAN (entre les VLAN), étudient et éliminent les questions discutées dans les questions de domaine de collision de dépannage et dépannent les sections lentes d'IntraVLAN (domaine d'émission) de ce document.

Le plus souvent, la Connectivité lente d'interVLAN est provoqué par par mauvaise configuration d'utilisateur. Par exemple, si vous configuriez inexactement MLS ou Multicast MultiLayer Switching (MMLS), puis le transfert de paquet est fait par la CPU de routeur, qui est un chemin lent. Pour éviter la mauvaise configuration et la dépanner efficacement si nécessaire, vous devriez comprendre le mécanisme utilisé par votre périphérique de l'expédition L3. Dans la plupart des cas, le mécanisme de transfert L3 est basé sur une compilation du routage et les tables de Protocole ARP (Address Resolution Protocol) et les informations extraites de programmation de transfert de paquet dans le matériel (raccourcis). N'importe quelle panne en cours de raccourcis de programmation mène à l'un ou l'autre de transfert de paquet de logiciel (un chemin lent), misforwarding (expédition à un port incorrect), ou trafique trouer noir.

Habituellement une panne de raccourci-programmation ou la création des raccourcis inachevés (qui peut également mener au logiciel le transfert de paquet, misforwarding, ou le noir du trafic trouant) est le résultat d'une erreur de programmation. Si vous suspectez ceci pour être cas, faites l'étudier aux ingénieurs de support technique de Cisco. D'autres raisons pour l'expédition lent d'interVLAN incluent des défaillances de matériel, toutefois ces causes sont hors de portée de ce document. Les défaillances de matériel empêchent simplement la création raccourcie réussie dans le matériel et, en conséquence, le trafic peut prendre un chemin lent (de logiciel) ou peut être noir troué. Des défaillances de matériel devraient être manipulées par des ingénieurs de support technique de Cisco, aussi bien.

Si vous êtes que le matériel est correctement configuré, mais commutation sûre de matériel n'a pas lieu, alors une erreur de programmation ou une défaillance de matériel peut être la cause. Cependant, rendez-vous compte des capacités de périphérique avant de former cette conclusion.

Ce qui suit sont les deux situations les plus fréquentes dans quand l'expédition de matériel peut cesser ou ne pas avoir lieu du tout :

  • La mémoire qui enregistre des raccourcis est épuisée. Une fois que la mémoire est pleine, le logiciel cesse habituellement davantage de création raccourcie. (Par exemple, MLS, si basé sur expédition exprès de NetFlow ou de Cisco, devient inactif une fois qu'il n'y a aucune pièce pour de nouveaux raccourcis, et il commute au logiciel [chemin lent].)

  • Le matériel n'est pas conçu pour exécuter la commutation de matériel, mais il n'est pas évident. Par exemple, les engines de superviseur de gamme Catalyst 4000 III et plus tard sont seulement le trafic IP matériel-en avant conçu ; tous autres types de trafic sont logiciel traité par la CPU. Un autre exemple est la configuration d'une liste de contrôle d'accès (ACL) qui exige l'intervention CPU (par exemple, avec l'option de « log »). Le trafic qui s'applique à cette règle est traité par la CPU en logiciel.

Les erreurs d'entrée sur un ½ du ¿  de switchï de cut-through peuvent également contribuer à la lenteur de routage d'interVLAN. Les commutateurs cut-through emploient les mêmes principes architecturaux pour expédier le trafic L3 et L2, ainsi les méthodes de dépannage fournies dans la section dépannent IntraVLAN lent (domaine d'émission), ci-dessus, peuvent être appliquées au trafic L2, aussi bien.

Un autre type de mauvaise configuration qui affecte le routage d'interVLAN est mauvaise configuration sur les périphériques d'utilisateur final (tels que le PC et les imprimantes). Une situation courante est un PC misconfigured ; par exemple, une passerelle par défaut misconfigured, la table ARP PC est non valide, ou le client IGMP a fonctionné mal. Un cas commun est quand il y a des plusieurs routeurs ou des périphériques routage-capables, et certains ou tous les PC d'utilisateur misconfigured pour utiliser la passerelle par défaut fausse. Ceci peut être le cas le plus ennuyeux, car tous les périphériques de réseau sont configurés et en fonctionnant correctement, cependant, les périphériques d'utilisateur final ne les utilisez pas en raison de cette mauvaise configuration.

Si un périphérique dans le réseau est un routeur régulier qui n'a aucune accélération de type de matériel (et ne participe pas au NetFlow MLS), alors le débit d'expédition du trafic dépend complètement de la vitesse de la CPU et comme il occupé est. L'utilisation du CPU élevé affecte certainement le taux à terme. Sur les Commutateurs L3, cependant, les états élevés CPU n'affectent pas nécessairement le taux à terme ; l'utilisation du CPU élevé affecte la capacité de la CPU de créer (programme) un raccourci matériel. Si le raccourci est déjà installé dans le matériel, alors même si la CPU est fortement utilisée, le trafic (pour le raccourci programmé) est commuté dans le matériel jusqu'à ce que le raccourci devienne obsolet (s'il y a un temporisateur d'expiration) ou est enlevé par la CPU. Cependant, si un routeur est configuré pour n'importe quelle accélération de type de logiciel (telle que la commutation rapide ou la commutation de Cisco Express Forwarding), puis le transfert de paquet peut être affecté par des raccourcis de logiciel ; si un raccourci est cassé, ou le mécanisme lui-même manque, alors au lieu du taux à terme étant accéléré, le trafic est donné un coup de volée à la CPU, ralentissant le taux à terme de données vers le bas.


Informations connexes


Document ID: 23637