Performances dégradées du réseau ATM

Introduction

Ce document traite des causes générales et spécifiques de la lenteur des performances sur les réseaux ATM et des procédures permettant de résoudre le problème. Ce document se concentre sur le dépannage des problèmes de performances IP, en particulier sur les réseaux ATM. En règle générale, les performances sont mesurées à l'aide du délai et du débit. Les performances sont souvent testées avec l'utilisation de FTP ou d'autres applications TCP/IP pour transférer un fichier entre deux périphériques finaux, puis mesurer le temps nécessaire au transfert du fichier. Lorsque le débit observé lors du transfert de fichiers n’est pas égal à la bande passante disponible sur le circuit ATM, cela est perçu comme un problème de performances. Il existe de nombreux facteurs, tels que les paramètres de fenêtre TCP, la MTU, la perte de paquets et le délai, qui déterminent le débit observé sur un circuit ATM. Ce document traite des problèmes qui affectent les performances des mises en oeuvre de circuits virtuels permanents (PVC) routés ATM, de circuits virtuels commutés (SVC) et d'émulation de LAN (LANE). La cause des problèmes de performances est commune entre les mises en oeuvre de circuits virtuels permanents routés, de circuits virtuels commutés et de réseaux locaux.

Conditions préalables

Conditions requises

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

Components Used

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

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Informations générales

La première étape du dépannage d'un problème lié aux performances consiste à sélectionner les périphériques source et de destination uniques à tester. Identifier les conditions dans lesquelles le problème se produit et celles dans lesquelles il ne se produit pas. Sélectionnez les périphériques de test pour réduire la complexité du problème. Par exemple, ne testez pas les périphériques qui sont séparés par dix sauts de routeur si le problème existe lorsque vous passez par deux routeurs.

Une fois les périphériques de test sélectionnés, déterminez si les performances sont liées à la nature inhérente des applications TCP ou si le problème est causé par d'autres facteurs. Envoyez une requête ping entre les périphériques finaux pour déterminer si la perte de paquets se produit et le délai aller-retour des paquets ping. Les tests ping doivent être effectués avec différentes tailles de paquet pour déterminer si la taille du paquet affecte la perte de paquet. Les tests ping doivent être effectués à partir des périphériques finaux testés et non à partir des routeurs. Le temps de trajet aller-retour (RTT) que vous voyez lorsque vous envoyez une requête ping à un routeur peut ne pas être exact. En effet, le processus ping est un processus de faible priorité sur le routeur et il peut ne pas répondre immédiatement à la requête ping.

Problèmes courants

Nature intrinsèque du protocole TCP/IP

Un client a un circuit virtuel permanent ATM entre New York et Los Angeles. Le circuit virtuel est configuré avec un débit de cellules soutenu (SCR) de 45 Mbits/s. Le client teste ce circuit en transférant un fichier FTP d’un serveur FTP à un client et découvre que le débit du transfert de fichiers est d’environ 7,3 Mbits/s. Lorsqu’ils utilisent TFTP, le débit passe à 58 Kbits/s. Le temps de réponse de la requête ping entre le client et le serveur est d’environ 70 ms.

La première chose à comprendre dans cet exemple est que le protocole TCP assure un transport fiable des données entre les périphériques. L'expéditeur envoie des données dans un flux dans lequel les octets sont identifiés par des numéros de séquence. Le destinataire reconnaît avoir reçu les données en envoyant le numéro d’ordre (numéro d’accusé de réception) de l’octet suivant des données qu’il s’attend à recevoir. Le destinataire annonce également sa taille de fenêtre à l'expéditeur pour annoncer la quantité de données qu'il peut accepter.

Les périphériques finaux TCP/IP incluent généralement la possibilité de configurer les tailles de fenêtres TCP/IP.

Si les tailles de fenêtre TCP des périphériques sont trop basses, ces périphériques peuvent ne pas pouvoir utiliser la bande passante totale d’un circuit virtuel ATM.

Le RTT sur un circuit virtuel ATM peut réduire considérablement le débit TCP si la taille de fenêtre est trop faible.

Un périphérique final envoie environ une valeur de trafic de taille de fenêtre en octets par RTT.

Par exemple, si le RTT est de 70 ms, utilisez cette formule pour calculer la taille de fenêtre nécessaire pour remplir un DS3 entier de bande passante :

• .07s * 45 Mbits/s * 1 octet/8 bits = 393 750 octets

Le protocole TCP standard autorise une taille de fenêtre maximale de 64 000 octets. L'option TCP WINScale permet d'augmenter considérablement la taille de la fenêtre si les périphériques des deux extrémités prennent en charge cette option et que l'application FTP prend également en charge cette option.

Utilisez cette formule pour définir la taille de la fenêtre à 64 000 octets et utilisez le RTT de 70 ms pour résoudre le débit.

• .07x * 1 octet/8 bits = 64 000 octets

  où x = 7,31428 Mbits/s

Si l'application FTP ne prend en charge qu'une taille de fenêtre de 32 000 octets, utilisez cette formule.

• 0,07x * 1 octet/8 bits = 32 000

  où x= 3,657142 Mbits/s

Avec TFTP, l’expéditeur envoie des paquets de 512 octets et doit recevoir un accusé de réception pour chaque paquet avant d’envoyer le paquet suivant. Le meilleur scénario est d'envoyer 1 paquet toutes les 70 ms. Utilisez ce calcul de débit.

• 1 paquet /.070s = 14,28571 paquets/seconde

  512 octets/paquet * 8 bits/octet * 14,28571 paquets/seconde = 58,514 Kbits/s

Ce calcul du débit montre que le délai sur une liaison et la taille de la fenêtre TCP peuvent affecter de manière spectaculaire le débit sur cette liaison lorsqu'elle utilise des applications TCP/IP pour mesurer le débit. Identifiez le débit attendu pour chaque connexion TCP. Si le protocole FTP est utilisé pour tester le débit, démarrez plusieurs transferts de fichiers entre différents clients et serveurs pour déterminer si le débit est limité par la nature inhérente du protocole TCP/IP ou s’il existe d’autres problèmes avec le circuit ATM. Si l'application TCP limite le débit, vous devriez pouvoir disposer de plusieurs serveurs qui envoient en même temps et à des taux similaires.

Ensuite, vérifiez que vous pouvez transmettre le trafic sur la liaison au débit SCR du circuit. Pour ce faire, utilisez une source de trafic et une liaison qui n’utilisent pas TCP et qui envoient un flux de données sur le circuit virtuel ATM. Vérifiez également que le taux reçu est égal au taux envoyé. Envoyez des paquets ping étendus à partir d’un routeur avec une valeur de temporisation 0 pour générer du trafic sur un circuit ATM. Cela prouve que vous pouvez envoyer du trafic sur la liaison au débit configuré du circuit.

Solution : Augmentez la taille de la fenêtre TCP/IP.

Important : Avec un très petit RTT et une taille de fenêtre suffisamment grande pour remplir théoriquement le SCR, vous ne pourrez jamais atteindre le SCR en raison de la surcharge ATM. Si vous prenez l'exemple des paquets de 512 octets envoyés sur un circuit virtuel permanent AAL5SNAP 4 Mbits/s (SCR=PCR), calculez le débit IP réel mesuré. Il est supposé que la taille de fenêtre TCP et le RTT sont tels que la source peut envoyer des données à 4 Mbits/s. Tout d’abord, la couche d’adaptation ATM 5 (AAL5) et le SNAP introduisent chaque 8 octets de surcharge. Pour cette raison, il peut être nécessaire de procéder à un remplissage afin de s'assurer que l'unité de données de protocole (PDU) AAL5 peut être divisée par 48. Ensuite, dans chaque cellule, 5 octets de surcharge sont introduits par cellule. Dans ce cas, cela signifie que la couche AAL5 est 512+8+8=528 octets (aucun remplissage nécessaire). Ces 528 octets nécessitent la transmission de 11 cellules. Cela signifie que pour chaque paquet de 512 octets à envoyer, 583 octets sont envoyés sur le câble (11 * 53). En d'autres termes, 71 octets de surcharge sont introduits. Cela signifie que seulement 88 % de la bande passante peut être utilisée par les paquets IP. Par conséquent, avec le circuit virtuel permanent 4 Mbits/s, cela signifie que le débit IP utilisable est d'environ 3,5 Mbits/s.

Plus la taille du paquet est petite, plus la surcharge est importante et le débit est faible.

La perte de paquets

La raison la plus courante des problèmes de performances est la perte de paquets sur les circuits ATM. Toute perte de cellules sur un circuit ATM entraîne une dégradation des performances. La perte de paquets signifie la retransmission, ainsi que la réduction de la taille des fenêtres TCP. Cela réduit le débit. En règle générale, un test ping simple identifie la perte de paquets entre les deux périphériques. Les erreurs CRC (Cyclic Redundancy Check) et les pertes de cellules/paquets sur les circuits ATM entraînent la retransmission des données. Si les cellules ATM sont rejetées par un commutateur ATM en raison de la réglementation ou de l'épuisement de la mémoire tampon, des erreurs CRC sont détectées sur le périphérique final lorsque les cellules sont réassemblées en paquets. Les périphériques de périphérie ATM peuvent abandonner ou retarder des paquets lorsque le débit de paquets sortants sur un circuit virtuel dépasse le débit de formatage de trafic configuré sur le circuit virtuel.

Reportez-vous à ces documents pour obtenir des détails sur le dépannage des causes les plus courantes de perte de paquets sur les réseaux ATM :

• Guide de dépannage CRC pour les interfaces ATM

• Résolution des problèmes liés de suppression de sorties sur les interfaces de routeur ATM

• Résolution des problèmes liés aux suppressions d'entrées dans les interfaces de routeur ATM

• Présentation des compteurs de cellules rejetées/ignorées sur les commutateurs-routeurs ATM

Solution : Dépannez et éliminez toute perte de paquets.

Délai/latence

Le temps nécessaire à un paquet pour se déplacer de la source à la destination, puis à un accusé de réception pour revenir à l’expéditeur, peut affecter considérablement le débit observé sur ce circuit. Le retard sur un circuit ATM peut être le résultat d’un délai de transmission normal. Il faut moins de temps pour envoyer un paquet de New York à Washington que de New York à Los Angeles lorsque le circuit ATM est à la même vitesse. Les autres sources de retard sont le délai de mise en file d’attente par les routeurs et les commutateurs et le délai de traitement par les périphériques de routage de couche 3. Le délai de traitement associé aux périphériques de routage dépend fortement de la plate-forme utilisée et du chemin de commutation. Les détails associés au délai de routage et au délai matériel interne ne sont pas abordés dans ce document. Ce délai affecte n’importe quel routeur, quels que soient les types d’interface. Il est également négligeable par rapport au délai associé à la transmission des paquets et à la mise en file d’attente. Cependant, si un routeur traite le trafic de commutation, il peut entraîner un retard important et doit être pris en compte.

Le délai est généralement mesuré à l’aide de paquets ping entre les périphériques finaux pour déterminer le délai moyen et le délai maximal aller-retour. Les mesures des retards doivent être effectuées pendant les périodes de pointe et d'inactivité. Cela permet de déterminer si le délai peut être attribué au délai de mise en file d’attente sur les interfaces encombrées.

La congestion des interfaces entraîne un délai de mise en file d’attente. L’encombrement résulte généralement d’incohérences de bande passante. Par exemple, si vous avez un circuit traversant un commutateur ATM qui traverse une interface OC-12 vers une interface DS3 ATM, vous risquez de connaître un délai de mise en file d’attente. Cela se produit lorsque les cellules arrivent sur l'interface OC-12 plus rapidement qu'elles ne peuvent être affichées sur l'interface DS3. Les routeurs de périphérie ATM configurés pour le formatage du trafic limitent le débit auquel ils sortent du trafic sur l’interface. Si le taux d’arrivée du trafic destiné au circuit virtuel ATM est supérieur aux taux de formatage du trafic sur l’interface, les paquets/cellules sont mis en file d’attente sur l’interface. En règle générale, le délai introduit par le délai de mise en file d'attente est le délai qui cause des problèmes de performances.

Solution : Implémenter des fonctions de classe de service (CoS) IP à ATM pour des services différenciés. Utilisez des fonctionnalités telles que CBWFQ (Class Based Weighted Fair Queuing) et LLQ (Low Latency Queuing) pour réduire ou éliminer le délai de mise en file d'attente pour le trafic critique. Augmentez la bande passante des circuits virtuels pour éliminer la congestion.

Configuration du formatage du trafic

Les circuits virtuels permanents et les circuits virtuels commutés ATM ont des paramètres de qualité de service (QoS) associés à chaque circuit. Un contrat de trafic est établi entre le périphérique de périphérie ATM et le réseau. Lorsque des circuits virtuels permanents sont utilisés, ce contrat est configuré manuellement dans le réseau ATM (commutateurs ATM). Avec les circuits virtuels commutés, la signalisation ATM est utilisée pour établir ce contrat. Les données de la forme de trafic des périphériques de périphérie ATM sont conformes au contrat spécifié. Les périphériques réseau ATM (commutateurs ATM) surveillent le trafic sur le circuit pour s’assurer qu’il est conforme au contrat spécifié et au trafic d’étiquette (marque) ou de rejet (police) qui n’est pas conforme.

Si le débit PCR/SCR d’un périphérique de périphérie ATM est supérieur à celui du réseau, la perte de paquets est probable. Les débits de formatage du trafic configurés sur le périphérique de périphérie doivent correspondre à ceux configurés de bout en bout sur le réseau. Vérifiez que la configuration correspond à tous les périphériques configurés. Si le périphérique de périphérie envoie sur le réseau des cellules qui ne sont pas conformes au contrat provisionné sur l'ensemble du réseau, les cellules rejetées dans le réseau sont généralement visibles. Ceci peut généralement être détecté par la réception d'erreurs CRC à l'extrémité distante lorsque le récepteur tente de réassembler le paquet.

Un périphérique de périphérie ATM avec PCR/SCR configuré pour un débit inférieur à celui du réseau entraîne une dégradation des performances. Dans ce cas, le réseau est configuré pour fournir plus de bande passante que le périphérique de périphérie n’envoie. Cette condition peut entraîner un délai de mise en file d’attente supplémentaire et même des pertes de file d’attente de sortie sur l’interface de sortie du routeur ATM de périphérie.

Les circuits virtuels commutés sont configurés sur les périphériques de périphérie, mais le réseau ne peut pas établir le circuit virtuel commuté de bout en bout avec les mêmes paramètres de trafic. Les mêmes concepts et problèmes s'appliquent aux circuits virtuels commutés qui s'appliquent aux circuits virtuels permanents. Le réseau ne peut pas configurer le circuit virtuel commuté de bout en bout avec les mêmes classes et paramètres QoS. Ce type de problème est généralement causé par un bogue ou des problèmes d'interopérabilité. Lorsqu'un circuit virtuel commuté est signalé, l'appelant spécifie les paramètres de mise en forme du trafic QoS dans la direction avant et arrière. Il peut arriver que l'appelé n'installe pas le circuit virtuel commuté avec les paramètres de mise en forme appropriés. La configuration de la mise en forme stricte du trafic sur les interfaces de routeur peut empêcher la configuration des circuits virtuels commutés avec des paramètres de mise en forme autres que ceux configurés.

L'utilisateur doit suivre le chemin du circuit virtuel commuté sur le réseau et vérifier qu'il est établi à l'aide de la classe QoS et des paramètres configurés sur le périphérique d'origine.

Solution : Éliminer les incohérences de configuration de la stratégie/formatage du trafic. Si des circuits virtuels commutés sont utilisés, vérifiez qu'ils sont configurés de bout en bout avec les paramètres de formatage/de réglementation appropriés. Configurez la mise en forme stricte du trafic sur les interfaces de routeur ATM à l'aide de la commande atm sig-traffic-formatage strict.

SVC qui routent sur des chemins non optimaux

Les circuits virtuels commutés configurés pour le débit non spécifié (UBR) peuvent être configurés sur des chemins non optimaux. Un circuit virtuel UBR est limité en bande passante au débit de ligne des liaisons traversées par le circuit virtuel. Par conséquent, si une liaison à haut débit tombe en panne, les circuits virtuels qui traversent cette liaison peuvent être rétablis sur une liaison plus lente. Même lorsque la liaison à haut débit est restaurée, les circuits virtuels ne sont pas démontés et rétablis sur la liaison la plus rapide. En effet, le chemin le plus lent satisfait aux paramètres QoS demandés (non spécifiés). Ce problème est très courant dans les réseaux LANE qui ont des chemins alternatifs à travers le réseau. Dans les cas où les chemins alternatifs ont la même vitesse de liaison, la défaillance d'une des liaisons entraîne le routage de tous les circuits virtuels commutés sur le même chemin. Cette situation peut affecter considérablement le débit et les performances du réseau, car la bande passante effective du réseau est réduite de moitié.

Même les circuits virtuels commutés à débit variable (VBR) et à débit constant (CBR) peuvent être routés sur des chemins non optimaux. Les périphériques finaux demandent des paramètres de trafic spécifiques (PCR, SCR, taille de rafale maximale {MBS}). L’objectif de la signalisation PNNI (Private Network-Network Interface) et ATM est de fournir un chemin qui répond aux exigences de QoS de la demande. Dans le cas des appels CBR et VBR-rt, cela inclut également le délai de transfert de cellule maximal. Un chemin peut satisfaire aux exigences spécifiées par le demandeur du point de vue de la bande passante, mais ne constitue pas le chemin optimal. Ce problème est fréquent lorsque des chemins à plus long délai répondent toujours aux besoins en bande passante des circuits virtuels VBR et CBR. Cela peut être perçu comme un problème de performances pour le client qui voit maintenant des caractéristiques de délai plus importantes sur le réseau.

Solution : Les circuits virtuels commutés d’un réseau ATM sont établis à la demande et ne sont généralement pas démontés et réacheminés sur un autre chemin, sauf si le circuit virtuel commuté est désactivé (en raison d’une inactivité ou d’une libération pour d’autres raisons). Les commutateurs ATM Cisco LightStream 1010 et Catalyst 8500 fournissent la fonctionnalité d'optimisation de la route PVC logicielle. Cette fonctionnalité permet de réacheminer dynamiquement un circuit virtuel permanent logiciel lorsqu'une meilleure route est disponible. Aucune fonctionnalité similaire n'est disponible pour les circuits virtuels commutés qui ne se terminent pas sur les commutateurs ATM.

Une solution possible à ce problème consiste à utiliser des circuits virtuels permanents entre les périphériques de périphérie ATM et les commutateurs ATM connectés. Les circuits virtuels permanents logiciels avec optimisation de route configurés entre les commutateurs ATM permettent de réacheminer le trafic des chemins non optimaux après une panne de liaison et une récupération ultérieure.

Configurez l'intervalle de temporisation d'inactivité pour les circuits virtuels commutés sur faible afin que les circuits virtuels commutés soient désactivés et rétablis plus fréquemment. Utilisez la commande idle-timeout seconds [minimum-rate] pour modifier la durée et les débits de trafic qui provoquent la désactivation du circuit virtuel commuté. Cela peut ne pas être très efficace, car le circuit virtuel doit être inactif pour être réacheminé sur le chemin optimal.

Si tout le reste échoue, assurez-vous que le chemin optimal a été restauré et rebondissez l’une des interfaces ATM associées au chemin redondant à vitesse lente ou l’une des interfaces de routeur qui termine le circuit virtuel commuté.

Problèmes relatifs au matériel

Problèmes de performances PA-A1

L'architecture de la carte de ports ATM PA-A1 et le manque de mémoire intégrée peuvent entraîner une dégradation des performances. Ce problème peut se manifester par l'abandon, le dépassement, les ignorations et les CRC sur l'interface. Le problème est aggravé lorsqu'il est utilisé avec un routeur Cisco 7200 avec NPE-100/175/225/300.

Référez-vous à Dépannage des erreurs d'entrée sur les cartes de ports ATM PA-A1 pour plus d'informations.

Solution : Remplacez les cartes de ports ATM PA-A1 par des cartes de ports ATM PA-A3 (au moins la révision 2) ou PA-A6.

PA-A3 version 1

La version 1 du matériel PA-A3 ne réassemble pas les cellules en paquets qui utilisent la mémoire vive statique intégrée (SRAM) de la carte de port. La carte transfère les cellules à travers le bus PCI (Periphine Component Interconnect) vers la mémoire hôte VIP (Versatile Interface Processor) ou NPE (Network Processing Engine) où elle réassemble les paquets. Cela entraîne des problèmes de performances similaires à ceux observés avec la carte de port ATM PA-A1.

Référez-vous à Dépannage des erreurs d'entrée et de sortie sur les cartes de ports ATM PA-A3 pour plus d'informations.

Solution : Remplacer les cartes de ports ATM PA-A3 (au moins la révision 2) ou PA-A6 par des cartes de ports ATM PA-A3 (révision 1).

Deux PA-A3 dans VIP2-50

Les cartes PA-A3-OC3SMM, PA-A3-OC3SMI et PA-A3-OC3SML sont conçues pour fournir des performances de commutation maximales lorsqu'une carte de port unique est installée dans un VIP2-50 unique. Un PA-A3-OC3SMM, PA-A3-OC3SMI ou PA-A3-OC3SML unique dans un VIP2-50 fournit jusqu'à 85 000 paquets par seconde de capacité de commutation dans chaque direction à l'aide de paquets de 64 octets. Notez qu'un PA-A3-OC3SMM, PA-A3-OC3SMI ou PA-A3-OC3SML peut utiliser à lui seul la capacité de commutation totale d'un VIP2-50 unique.

Pour les applications nécessitant une densité de port maximale ou un coût système inférieur, les configurations à deux ports avec la version OC-3/STM-1 de la carte PA-A3 dans le même VIP2-50 sont désormais prises en charge. Les deux cartes de ports du même VIP2-50 partagent environ 95 000 paquets par seconde de capacité de commutation dans chaque direction à l'aide de paquets de 64 octets.

Le VIP-50 fournit jusqu'à 400 mégabits par seconde (mbits/s) de bande passante totale selon les combinaisons de cartes de ports. Dans la plupart des configurations à deux ports avec PA-A3-OC3SMM, PA-A3-OC3SMI ou PA-A3-OC3SML, la combinaison des cartes de ports dépasse cette capacité de bande passante globale.

Par conséquent, les performances partagées entre les deux cartes de ports installées dans le même VIP2-50 sont limitées par la capacité de commutation agrégée (95 kpps) aux petites tailles de paquets et par la bande passante agrégée (400 mbps) aux grandes tailles de paquets.

Ces restrictions de performances doivent être prises en compte lorsque vous désignez des réseaux ATM avec les cartes PA-A3-OC3SMM, PA-A3-OC3SMI ou PA-A3-OC3SML. Selon la conception, les performances des cartes à deux ports dans le même VIP2-50 peuvent être ou non acceptables.

Référez-vous à Configurations VIP2 PA-A1 et PA-A3 prises en charge pour plus d'informations.

Problèmes de LANE

Domaine de diffusion LANE

Un nombre excessif de systèmes d’extrémité dans un LAN ELAN LANE unique peut considérablement dégrader les performances de toutes les stations d’extrémité. Un ELAN représente un domaine de diffusion. Toutes les stations de travail et tous les serveurs au sein du réseau ELAN reçoivent du trafic de diffusion et éventuellement de multidiffusion de tous les autres périphériques du réseau ELAN. Si le niveau de trafic de diffusion est élevé par rapport à la capacité de traitement de la station de travail, les performances de la station de travail en pâtissent.

Solution : Limitez le nombre de stations d’extrémité dans un seul réseau local Ethernet à moins de 500. Surveillez le réseau à la recherche de tempêtes de diffusion/multidiffusion susceptibles d'affecter les performances du serveur/de la station de travail.

Référez-vous à Recommandations de conception LANE pour plus d'informations.

Trafic LE-ARP excessif et modifications de topologie Spanning Tree

Les autres problèmes qui peuvent entraîner des performances médiocres dans un réseau LANE sont l’activité excessive du protocole LANE ARP (LE-ARP) et les modifications de topologie Spanning Tree. Ces problèmes conduisent à des LE-ARP non résolus qui conduisent au trafic envoyé par le bus. Cela peut également conduire à une utilisation élevée du CPU sur les LEC du réseau, ce qui peut également entraîner des problèmes liés aux performances. Pour plus d'informations sur ces problèmes, consultez Dépannage de Spanning Tree sur LANE.

Configurez Spanning Tree PortFast sur les ports hôtes des commutateurs Ethernet connectés au LAN pour réduire les modifications de topologie Spanning Tree. Configurez la revérification LE-ARP locale sur les commutateurs Catalyst 5000 et 6000 configurés pour LANE afin de réduire le trafic LE-ARP.

VBR-nrt Data Direct SVC

À l'aide de la version 1 de LANE, les circuits virtuels commutés sont configurés en tant que catégorie de service UBR. LANE version 2 prend en charge la possibilité d'établir des circuits virtuels commutés Data Direct à l'aide d'autres catégories de services comme VBR-nrt. Un fournisseur tiers a un bogue dans l'implémentation de son client LANE qui peut faire que les SVC Data Direct configurés sur des périphériques Cisco soient VBR-nrt avec un SCR de 4 Kbits/s. Si votre réseau fédérateur ATM est constitué de liaisons de liaison OC-3 (155 Mbits/s) et OC-12 (622 Mbits/s) et que vous configurez le circuit virtuel commuté sur ces liaisons avec un débit de cellules soutenu de 4 Kbits/s, vos performances en pâtissent. Bien que ce problème particulier ne soit pas courant, il souligne un besoin important lorsque vous dépannez des problèmes de performances sur des circuits ATM. Vous devez suivre le chemin parcouru par vos circuits virtuels commutés sur le réseau et confirmer que le circuit virtuel a été établi avec la catégorie de service et les paramètres de trafic souhaités.

Les circuits virtuels directs de données ne sont pas établis

Les circuits virtuels directs de données LANE sont des circuits virtuels commutés bidirectionnels point à point configurés entre deux clients d’émulation de réseau local (LEC) et utilisés pour échanger des données entre ces clients. Les clients LANE envoient des requêtes LE-ARP pour connaître les adresses ATM associées à une adresse MAC. Ils tentent ensuite de configurer un circuit virtuel Data Direct vers cette adresse ATM. Avant l'établissement du circuit virtuel Data Direct, les clients LANE inondent des paquets de monodiffusion inconnus vers le serveur de diffusion et d'inconnu (BUS). Un client LANE peut ne pas établir de circuit virtuel Data Direct vers un autre LEC dans le but de lui envoyer des données de monodiffusion. Si cela se produit, la dégradation des performances peut en résulter. Le problème est important si le périphérique choisi pour exécuter les services BUS est sous-alimenté, inadéquat ou surchargé. En outre, certaines plates-formes peuvent attribuer un débit limite aux monodiffusions transmises au BUS. Le module LANE Catalyst 2900XL est l'un de ces boîtiers qui limite le trafic de monodiffusion envoyé au BUS, contrairement aux Catalyst 5000 et Catalyst 6000.

Le circuit virtuel commuté Data Direct peut ne pas être établi ou utilisé pour l'une des raisons suivantes :

• Le LEC ne reçoit pas de réponse à la requête LE-ARP.

• Impossible de créer le circuit virtuel commuté en raison de problèmes de routage ou de signalisation ATM.

• Échec du protocole LANE Flush Message Protocol. Une fois que le circuit virtuel direct de données est établi, le LEC envoie une requête de vidage sur le circuit virtuel d'envoi multidiffusion pour s'assurer que toutes les trames de données qui ont été envoyées via le bus BUS ont atteint leur destination. Lorsque le LEC qui a envoyé la demande de vidage reçoit une réponse, il commence à envoyer des données sur le circuit virtuel Data Direct. Le mécanisme de vidage peut être désactivé avec la commande no lane client flush.

Problèmes IMA

PVC UBR sur les interfaces IMA

Les circuits virtuels UBR sur les interfaces IMA (Inverse Multiplexing) sont configurés avec une PCR de 1,5 Mbits/s au lieu de la somme de toutes les interfaces physiques up/up configurées dans le groupe IMA. Cette condition dégrade les performances car le circuit virtuel est formé à un débit inférieur à la bande passante combinée de toutes les liaisons du groupe IMA.

À l'origine, la bande passante d'une interface de groupe IMA était limitée au nombre minimum de liaisons IMA actives nécessaires pour maintenir l'interface IMA en service. La commande permettant de définir cette valeur est IMA active-links-minimum. Par exemple, si quatre interfaces ATM physiques sont configurées en tant que membres du groupe IMA zéro et que la valeur IMA active-links-minimum est définie sur un, la bande passante est égale à un T1 ou 1,5 Mbits/s et non à 6 Mbits/s.

L'ID de bogue Cisco CSCdr12395 (clients enregistrés uniquement) change ce comportement. La carte PA-A3-8T1IMA utilise désormais la bande passante de toutes les interfaces physiques ATM up/up configurées en tant que membres du groupe IMA.

Les ID de bogue Cisco CSCdt67354 (clients enregistrés uniquement) et CSCdv67523 (clients enregistrés uniquement) sont des demandes d'amélioration ultérieures pour mettre à jour la bande passante VC du groupe IMA lorsqu'une interface est ajoutée ou supprimée du groupe IMA, arrêtée/non fermée ou rebondiscontinue en raison d'une panne ou d'une liaison, modifier à l'extrémité distante. Les modifications mises en oeuvre dans le bogue Cisco IDCSCdr12395 (clients enregistrés uniquement) configurent la bande passante du groupe IMA sur la bande passante totale de ses liaisons membres uniquement lorsque le groupe IMA apparaît. Les modifications apportées au groupe IMA après le statut initial ne sont pas prises en compte.

Référez-vous à Dépannage des liaisons ATM sur l'adaptateur de port IMA 7x00 pour plus d'informations.

Informations connexes

• Sélection de route PNNI (Private Network-to-Network Interface)
• Évolutivité des fenêtres TCP
• Dépannage des liaisons ATM sur l'adaptateur de port IMA 7x00
• Configurations PA-A1 et PA-A3 VIP2 prises en charge
• Détails de l'implémentation TCP/IP de Microsoft Windows 2000
• Dépannage de TCP/IP
• Support technique - Cisco Systems

Historique de révision