Foire aux questions - Abandons de sortie sur les commutateurs Cisco Catalyst 9000

Introduction

Ce document fournit des réponses aux questions courantes concernant les pertes de sortie sur les commutateurs de la gamme Cisco Catalyst 9000.

Conditions préalables

Exigences

Cisco recommande que vous ayez une compréhension fondamentale des concepts de commutation, y compris la mise en mémoire tampon des interfaces et les configurations de qualité de service (QoS).

Composants utilisés

Ce document s'applique à tous les commutateurs de la gamme Cisco Catalyst 9000 et n'est pas limité à des versions matérielles ou logicielles spécifiques.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Les pertes de sortie se produisent lorsqu’une mémoire tampon de sortie d’interface est épuisée, ce qui entraîne une perte de paquets et une dégradation des performances du réseau. Les causes les plus courantes sont l'encombrement du réseau, les micro-salves de trafic, les erreurs de configuration ou les limitations matérielles. Ce document de FAQ répond aux questions courantes concernant les pertes de sortie sur les commutateurs de la gamme Cisco Catalyst 9000. Il fournit des conseils sur l'identification des causes premières, les méthodologies de dépannage et les pratiques recommandées pour restaurer l'efficacité et la fiabilité du réseau.

Q. Que sont les pertes de sortie ?

R. Les abandons de sortie sur les commutateurs Cisco Catalyst 9000 font référence au nombre de paquets abandonnés et non transmis à partir d'une interface, même si les paquets ont été traités par le périphérique. Cela se produit lorsque la file d'attente de sortie de l'interface est pleine. L’interface du commutateur dispose de mémoires tampon matérielles qui stockent temporairement les paquets avant qu’ils ne soient transmis ou transférés hors du port. Lorsque le débit du trafic sortant dépasse le débit auquel le matériel peut le transmettre, les tampons deviennent pleins et tous les paquets supplémentaires arrivant dans la file d'attente sont abandonnés.

Q. Quelle commande peut être utilisée pour vérifier les pertes de sortie ?

A. Utilisez la commande show interfaces <interface> et recherchez le compteur total de pertes en sortie, qui indique le nombre de paquets abandonnés dans la file d’attente de sortie de cette interface.

Exemple :

GigabitEthernet1/0/1 is up, line protocol is up (connected)
  Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 3089
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)

Q. Quelles sont les causes courantes des pertes de sortie ?

R. Les pertes de sortie sur les commutateurs Catalyst 9000 se produisent généralement lorsque des paquets sont rejetés avant la transmission en raison de divers problèmes de congestion ou de configuration. Les causes courantes sont les suivantes :

• Micro-salves de trafic : Pics soudains et de haute intensité du trafic qui se produisent en quelques millisecondes. Étant donné que les outils de surveillance réseau standard (tels que SNMP) effectuent souvent des interrogations à des intervalles d'une minute ou de cinq minutes, ces rafales sont souvent invisibles pour le logiciel de gestion, mais sont suffisantes pour épuiser les tampons de sortie du matériel.
• Sursouscription : Lorsque la bande passante totale du trafic entrant dépasse de manière significative la capacité de l'interface de sortie, l'encombrement est inévitable. Ceci est courant dans les scénarios où plusieurs ports haut débit (par exemple, 10G) envoient le trafic vers un seul port bas débit (par exemple, 1G).
• Contraintes de tampon : Chaque interface dispose d’une quantité limitée d’espace mémoire tampon matériel. Lorsque la file d'attente de sortie atteint sa capacité maximale en raison d'un encombrement prolongé, le commutateur effectue un « tail-drop », où tous les paquets entrants suivants sont rejetés jusqu'à ce que de l'espace soit disponible.
• Mauvaise configuration de la qualité de service (QoS) : Des stratégies QoS mal configurées, notamment une stratégie agressive ou une mise en forme restrictive, peuvent entraîner des pertes. Si une stratégie est configurée pour limiter le trafic en dessous de la capacité réelle de la liaison, les paquets dépassant ce seuil seront abandonnés même si la liaison physique n'est pas encombrée.
• Discordances de vitesse et de duplex : Bien que cela soit moins courant avec la négociation automatique moderne, une non-correspondance entre le port de commutateur et le périphérique connecté peut entraîner une transmission inefficace, une augmentation des collisions (en mode bidirectionnel non simultané) et une saturation ultérieure de la file d'attente.
• Contrôle de flux (IEEE 802.3x) : Si le contrôle de flux est activé, le commutateur peut être invité à interrompre la transmission par le périphérique récepteur. Si les trames de pause sont fréquentes, la sortie des tampons du commutateur peut se remplir, entraînant des pertes pendant que le commutateur attend pour reprendre la transmission.
• Déséquilibre Port-Channel : si le trafic dans un EtherChannel/Port-Channel n'est pas réparti uniformément sur les liaisons membres, une interface peut devenir encombrée tandis que d'autres restent sous-utilisées.

Q. Que sont les micro-salves ?

R. Les micro-salves sont des pics de trafic de courte durée et de haute intensité qui se produisent sur des microsecondes ou des millisecondes. Ils provoquent des pertes de sortie en épuisant instantanément les tampons matériels de sortie sur les commutateurs Catalyst 9000. Comme les outils de surveillance standard font la moyenne du trafic sur des intervalles plus longs, ces rafales restent souvent invisibles. Cela entraîne une perte de paquets même lorsque l'utilisation moyenne d'une interface semble bien dans la capacité. Par conséquent, ces pics transitoires sont une cause principale d’encombrement dans les environnements réseau à haut débit.

Q. Les pertes de sortie posent-elles toujours problème ?

R. Non, des pertes de sortie peuvent se produire pendant de courtes rafales de trafic, même dans des réseaux sains. Les commutateurs modernes utilisent la mise en file d’attente basée sur la mémoire tampon et des abandons occasionnels peuvent se produire sans affecter les applications. Les abandons deviennent généralement problématiques lorsque :

• Les gouttes augmentent continuellement

• Les applications connaissent la latence ou la perte de paquets

• Augmentation des retransmissions TCP

• Les applications en temps réel (VoIP/vidéo) sont affectées

Q. Pourquoi les pertes de sortie se produisent-elles même lorsque l’interface n’est pas entièrement utilisée ?

R. Des pertes de sortie peuvent se produire même lorsque l’utilisation de l’interface est bien inférieure à la bande passante maximale de la liaison (par exemple, inférieure à 1 000 Mbits/s sur une interface Gigabit). Cela est dû au fait que le trafic réseau n’est pas transmis dans un flux parfaitement fluide et continu. Dans un scénario idéal, chaque bit est transmis uniformément sur la liaison et tous les périphériques envoient le trafic à des intervalles synchronisés avec précision. Cependant, dans les réseaux réels, les périphériques transmettent le trafic quand ils en ont besoin. Par conséquent, plusieurs paquets peuvent arriver au commutateur en même temps et doivent être transmis via la même interface de sortie. Afin de gérer cette situation, les commutateurs utilisent des tampons matériels sur chaque interface. Ces tampons stockent temporairement les paquets qui arrivent simultanément afin qu'ils puissent être transmis séquentiellement sur la liaison. Si le volume de paquets arrivant à l'interface à un moment donné dépasse la capacité de mémoire tampon disponible, le commutateur ne peut pas les stocker tous. Dans ce cas, les paquets excédentaires sont abandonnés, ce qui entraîne des abandons de sortie.

C'est pourquoi il est possible d'observer des pertes de sortie même lorsque l'utilisation moyenne de la bande passante est relativement faible (par exemple, 300 Mbits/s sur une interface 1 Gbits/s). L'utilisation moyenne peut sembler faible, mais de courtes rafales de trafic peuvent momentanément dépasser la capacité de l'interface à transmettre des paquets ou dépasser la capacité de mémoire tampon disponible.

Il est également important de noter que les valeurs d'utilisation d'interface affichées par les outils de surveillance SNMP ou la commande show interface sont basées sur des mesures de trafic moyennes sur des intervalles tels que 30 secondes ou 5 minutes. Ces moyennes ne reflètent pas les pics de trafic très courts qui peuvent se produire en quelques millisecondes.

Q. Comment contrôler les pertes de sortie sans augmenter la vitesse de la liaison ?

R. Vous pouvez gérer et réduire les pertes de sortie sur les commutateurs Catalyst 9000 grâce à plusieurs techniques sans mettre à niveau la vitesse de liaison physique :

• Increase the SoftMax Multiplier (Quick Mitigation) : pour augmenter le nombre de tampons qu'une file d'attente peut demander à partir du pool de tampons partagés, vous pouvez ajuster le seuil SoftMax à l'aide de la commande de configuration globale qos queue-softmax-multiplicer <100-1200>. La valeur par défaut est 100. Si cette valeur est définie sur 1200, la file d'attente peut absorber des microrafales d'un facteur 12 par rapport à la configuration par défaut.

  Cette commande augmente les seuils de file d'attente de port de sorte que la file d'attente puisse consommer des unités de mémoire tampon supplémentaires du pool de mémoires tampons partagées si nécessaire. Cette technique est généralement utilisée comme technique de réduction rapide des pertes de sortie causées par les rafales de trafic. Cependant, comme les tampons sont des ressources partagées, la configuration suppose que les microrafales ne se produisent pas simultanément sur tous les ports.

Modification de la mémoire tampon par file d'attente (réglage de la stratégie QoS) : si le multiplicateur SoftMax est insuffisant, l'allocation de mémoire tampon peut être réglée au niveau de la file d'attente à l'aide de mappages de stratégie QoS. Cela permet aux administrateurs d'allouer plus d'espace tampon à des classes de trafic spécifiques, de modifier les ratios de tampon de file d'attente et de configurer des files d'attente prioritaires pour le trafic critique. Cette approche est utile lorsque des types de trafic spécifiques nécessitent des ressources de mémoire tampon dédiées ou lorsque les profils de trafic varient considérablement.

Exemple :

policy-map QOS-POLICY
 class VOICE
  priority level 1
  queue-buffers ratio 50
 class class-default
  queue-buffers ratio 50

• Implémenter la qualité de service (QoS) : Il permet de contrôler les pertes de paquets en hiérarchisant le trafic réseau critique pendant les périodes d'encombrement. Elle permet aux réseaux de hiérarchiser le trafic sensible à la latence, comme la voix et la vidéo, de protéger le trafic du plan de contrôle et de s'assurer que les données importantes sont transmises avant le trafic de moindre priorité. Les mécanismes QoS typiques incluent la classification du trafic, la hiérarchisation des files d'attente, l'allocation de tampons de files d'attente et la gestion des encombrements. En appliquant ces techniques, le réseau peut s'assurer que le trafic moins important est abandonné en premier, ce qui contribue à protéger les applications critiques de l'entreprise et à maintenir les performances globales du réseau.

• Traffic Shaping : configurez le formatage de sortie sur l'interface pour lisser les rafales de trafic. En plafonnant le débit de transmission légèrement en dessous du débit de ligne physique, vous forcez le trafic à être mis en mémoire tampon et envoyé à un débit cohérent et prévisible. Cela permet d'éviter le comportement de chute de la queue provoqué par des micro-salves soudaines à grande vitesse.

Exemple :

policy-map SHAPE-POLICY
 class class-default
  shape average 

• Optimiser la répartition de la charge (équilibrage port-canal) : Dans une configuration EtherChannel ou Port-Channel, un hachage inégal peut entraîner l'encombrement de liaisons membres spécifiques alors que d'autres restent sous-utilisées. En optimisant les algorithmes d’équilibrage de charge, vous vous assurez que le trafic est réparti uniformément sur toutes les liaisons membres, ce qui évite l’encombrement sur les interfaces individuelles et réduit les pertes de sortie.

Exemple :

port-channel load-balance src-dst-ip

Q. Quelle est la meilleure solution pour les pertes de sortie ?

R. Les solutions les plus efficaces pour éliminer les pertes de sortie sont les suivantes :

• Augmenter la vitesse de ligne de l'interface : mettez à niveau la vitesse de l'interface pour fournir une bande passante de sortie plus élevée et réduire le surabonnement. Par exemple, passez d'une interface 1G à une interface 10G si disponible sur le commutateur.
• Utiliser le regroupement de ports (EtherChannel) : regroupe plusieurs liaisons physiques en une seule liaison logique à l'aide du regroupement de ports, à condition que le périphérique connecté prenne en charge cette fonctionnalité. Cela augmente la bande passante globale et aide à répartir la charge de trafic.
• Mise à niveau matérielle si nécessaire : si une interface à vitesse plus élevée n'est pas disponible sur le commutateur et que le regroupement de ports n'est pas pris en charge par le périphérique connecté, envisagez de mettre à niveau la plate-forme matérielle vers une plate-forme avec une capacité plus élevée ou des mémoires tampons plus importantes.

Q. Comment les statistiques de file d’attente peuvent-elles être vérifiées sur une interface ?

R. Pour les commutateurs Catalyst 9000, les statistiques détaillées de la file d’attente matérielle peuvent être vérifiées à l’aide de la commande show platform hardware fed active qos queue stats interface <port>. Cette commande fournit des statistiques détaillées, notamment l'utilisation de la mémoire tampon, le nombre de files d'attente et les compteurs de suppression par file d'attente sur l'interface spécifiée, ce qui permet de surveiller les performances de la file d'attente et d'identifier l'encombrement ou les pertes de paquets.

Exemple :

show platform hardware fed switch active qos queue stats interface Gig 1/0/1
DATA Port:0 Enqueue Counters
---------------------------------------------------------------------------------------------
Q Buffers          Enqueue-TH0          Enqueue-TH1          Enqueue-TH2             Qpolicer
  (Count)              (Bytes)              (Bytes)              (Bytes)              (Bytes)
- ------- -------------------- -------------------- -------------------- --------------------
0       0                    0                    0            384251797                    0
1       0                    0                    0         488393930284                    0
...
DATA Port:0 Drop Counters
-------------------------------------------------------------------------------------------------------------------------------
Q             Drop-TH0             Drop-TH1             Drop-TH2             SBufDrop              QebDrop         QpolicerDrop
               (Bytes)              (Bytes)              (Bytes)              (Bytes)              (Bytes)              (Bytes)
- -------------------- -------------------- -------------------- -------------------- -------------------- --------------------
0                    0                    0                    0                    0                    0                    0
1                    0                    0            192308101                    0                    0                    0
...

Q. Comment confirmer si la qualité de service entraîne des pertes de sortie ?

R. Afin de vérifier si la QoS est responsable des abandons de sortie, vérifiez les statistiques de la politique de QoS en utilisant la commande show policy-map interface <interface> et les compteurs de file d'attente. Si les compteurs d'abandon augmentent sous une classe de QoS spécifique, les abandons peuvent être provoqués par des limites de file d'attente de QoS ou la réglementation. Si possible, pendant une fenêtre de maintenance, supprimez temporairement la politique de QoS de l'interface en utilisant la commande no service-policy output <policy-name> et surveillez si les abandons de sortie continuent. Si les abandons s'arrêtent après la suppression de la stratégie, il est probable que la configuration QoS y contribue.

Exemple :

sh policy-map interface gigabitEthernet 1/0/1
GigabitEthernet1/0/1
Service-policy output: TEST
Class-map: class-default (match-any)
0 packets
Match: any
Queueing
(total drops) 587230
(bytes output) 834545
...

Q. Les pertes de sortie peuvent-elles se produire sur des interfaces haut débit telles que 10G ou 40G ?

R. Oui, même les interfaces à haut débit telles que 10G ou 40G peuvent subir des pertes de sortie lorsque plusieurs flux à haut débit convergent sur un seul port, provoquant la saturation des tampons d’interface. En outre, les microrafales, c'est-à-dire de courtes rafales de trafic qui dépassent la bande passante de l'interface, peuvent rapidement épuiser les tampons des ports et entraîner des pertes de paquets.

Q. Les pertes de sortie peuvent-elles être causées par des défaillances matérielles ?

R. Les pertes de sortie ne sont généralement pas causées par des défaillances matérielles. Ils résultent généralement d'un encombrement du trafic, où les tampons de l'interface sont saturés en raison de débits de trafic élevés ou de microrafales. Des abandons liés au matériel peuvent se produire, mais ils sont généralement liés à des conditions d'erreur spécifiques, qui sont rares par rapport aux abandons liés à l'encombrement. Par conséquent, les pertes en sortie sont principalement associées aux conditions de trafic réseau plutôt qu'aux pannes matérielles. La surveillance des erreurs d'interface, telles que les erreurs FCS/CRC, peut aider à identifier les problèmes matériels, le cas échéant, mais ces erreurs sont distinctes des pertes de sortie provoquées par l'encombrement.

Q. Les bogues logiciels peuvent-ils entraîner des pertes de sortie ?

R. Les pertes de sortie causées par des défauts logiciels sont très rares et surtout cosmétiques, n'ayant pas d'impact significatif sur le trafic. La plupart des pertes de sortie sont principalement dues à la congestion du trafic et à l'épuisement de la mémoire tampon.

Q. Le protocole ECMP ou l'équilibrage de charge peuvent-ils réduire la congestion ?

R. Oui, le routage ECMP (Equal-Cost Multi-Path) et l'équilibrage de charge réduisent l'encombrement en répartissant le trafic de manière égale entre plusieurs chemins de coût égal vers une destination. Cette approche augmente l'utilisation de la bande passante et empêche tout chemin unique de devenir un goulot d'étranglement.

Q. Les pertes de sortie affectent-elles le trafic UDP différemment du trafic TCP ?

R. Oui, les pertes de sortie affectent le trafic UDP différemment du trafic TCP, car le protocole UDP est un protocole non orienté connexion qui ne retransmet pas les paquets perdus. Par conséquent, toute perte de paquet affecte directement les applications telles que la voix ou la vidéo, qui dépendent de la livraison en temps voulu. En revanche, le protocole TCP inclut des mécanismes de retransmission qui tentent de récupérer les paquets perdus, réduisant ainsi l’impact des abandons. Par conséquent, les pertes de sortie peuvent entraîner une dégradation plus visible dans les applications UDP en temps réel, car les paquets perdus ne sont pas récupérés et peuvent entraîner des problèmes de qualité.

Q. Quelle est la différence entre les pertes en entrée et les pertes en sortie ?

R. Les pertes d’entrée sur les interfaces se produisent généralement lorsque les files d’attente d’entrée sont saturées et ne peuvent pas traiter les paquets assez rapidement, ce qui entraîne l’abandon sélectif des paquets en fonction de l’algorithme de mise en file d’attente. Les abandons de sortie se produisent lorsque des paquets sont abandonnés alors qu'ils quittent une interface en raison d'un encombrement dans la file d'attente de sortie ou d'un épuisement de la mémoire tampon. Les pertes en entrée sont liées aux limites de traitement en entrée, tandis que les pertes en sortie sont principalement dues à la congestion en sortie et au dépassement de capacité de la mémoire tampon. Ces abandons peuvent être influencés par des facteurs tels que les pics de trafic, les limitations de plate-forme et les configurations de qualité de service (QoS) qui gèrent l'encombrement et l'allocation de mémoire tampon.

Q. Les tâches de sauvegarde volumineuses peuvent-elles entraîner des pertes de sortie ?

R. Oui, les tâches de sauvegarde volumineuses, telles que les sauvegardes de données, la réplication ou les transferts en masse, génèrent souvent un trafic par salves qui peut submerger les tampons d'interface, entraînant des pertes de sortie. Ces salves peuvent entraîner un encombrement temporaire sur l'interface de sortie, en particulier lorsque la bande passante sortante est inférieure au débit du trafic entrant ou lorsque plusieurs flux à haut débit convergent sur un seul port.

Q. Comment puis-je identifier si les rafales de trafic provoquent des pertes de sortie ?

R. Afin de confirmer les abandons de sortie causés par des rafales de trafic, vous pouvez utiliser une session SPAN combinée à Wireshark pour capturer et analyser le trafic de sortie sur l'interface affectée pendant que des abandons de sortie se produisent. Observez ces étapes afin de vérifier les abandons de sortie déclenchés par des rafales de trafic.

• Connectez un ordinateur portable équipé de Wireshark à un port inutilisé du commutateur.
• Configurez la fonctionnalité SPAN sur le commutateur pour mettre en miroir le trafic de sortie de l'interface rencontrant des pertes de sortie vers le port où l'ordinateur portable est connecté.

monitor session 1 source interface  Tx
monitor session 1 destination interface 

Replace  with the interface where output drops are seen for the source.
Replace  with the interface connected to the laptop for the destination.

• Démarrez la capture SPAN sur le commutateur pendant que les pertes de sortie s'incrémentent activement pour garantir la capture du trafic approprié.
• Ouvrez le fichier de capture dans Wireshark, puis accédez à Statistics > I/O Graph.
• Modifiez l'intervalle de la valeur par défaut de 1 seconde à 1 milliseconde (1 ms).
• Cliquez sur Reset afin d'actualiser le graphique avec le nouvel intervalle.
• Le graphique affiche le trafic en bits par milliseconde.

Recherchez les pics de trafic qui dépassent la vitesse de transmission de l'interface sur une échelle de millisecondes (par exemple, 1 000 000 bits/ms pour une interface 1 GBPS). Lorsque le trafic dépasse cette vitesse de transfert, le commutateur met les paquets en mémoire tampon, ce qui peut entraîner un encombrement et des pertes de sortie. Identifiez les salves de trafic (microsalves) en observant les pics suivis de périodes de trafic faible ou nul. Dans Wireshark, le fait de cliquer sur un pic sélectionne les paquets correspondants, ce qui permet une analyse plus approfondie du trafic qui a déclenché les abandons. L'image suivante présente le graphique d'E/S mis à jour pour une interface qui a subi des pertes de sortie.

Considérations importantes

• Assurez-vous que les ports source et de destination de la fonctionnalité SPAN ont des vitesses identiques ou compatibles afin d'éviter l'introduction de pertes supplémentaires.
• Capturer le trafic pendant que les pertes de sortie augmentent activement pour capturer les rafales pertinentes.
• La capture de paquets intégrée (EPC) n'est pas recommandée à cette fin, car elle limite les taux de capture et peut manquer des rafales.

Idées fausses courantes sur les pertes de sortie

Idée fausse : Toute perte de sortie signifie que le réseau ne fonctionne pas correctement.

Réalité : Un petit nombre de pertes en sortie est normal dans les réseaux à haut débit en raison de microrafales ou de pics de trafic courts.

Idée fausse : Si l'utilisation de l'interface est faible, les abandons ne doivent pas se produire.

Réalité : L'utilisation se mesure en moyenne dans le temps. Les microrafales peuvent temporairement dépasser la bande passante de l'interface, provoquant des pertes même lorsque l'utilisation moyenne est faible.

Idée fausse : Les pertes de sortie signifient que le matériel du commutateur est défectueux.

Réalité : Les pertes de sortie sont généralement causées par un encombrement du trafic ou un trafic par salves, et non par des problèmes matériels.

Idée fausse : L'augmentation de l'allocation de mémoire tampon empêchera toutes les pertes.

Réalité : Les tampons absorbent uniquement les rafales temporaires. Un encombrement persistant entraînera toujours des abandons de paquets.

Idée fausse : Seules les interfaces 1G subissent des pertes de sortie.

Réalité : Des abandons peuvent se produire sur des interfaces 10G, 25G, 40G ou plus rapides lorsque les rafales de trafic dépassent la bande passante disponible ou la capacité de la mémoire tampon.

Idée fausse : la qualité de service doit éliminer toutes les suppressions/empêcher la perte de paquets.

Réalité : La QoS donne la priorité au trafic important, mais elle peut intentionnellement abandonner le trafic de moindre priorité en cas d'encombrement.

Idée fausse : Toute perte de sortie aura un impact sur l'utilisateur.

Réalité : De nombreuses applications utilisent la retransmission TCP, qui peut récupérer des paquets abandonnés occasionnellement sans impact notable.

Idée fausse : Les abandons se produisent uniquement lorsque les interfaces atteignent une utilisation de 100 %.

Réalité : Des abandons peuvent se produire pendant de courtes rafales de trafic, même si l'utilisation moyenne reste faible.

Idée fausse : La configuration QoS est toujours la cause des abandons.

Réalité : La plupart des abandons sont dus à des modèles de trafic ou à un surabonnement, et non à des politiques de QoS.

Idée fausse : Un réseau sain ne doit jamais avoir de pertes de sortie.

Réalité : Dans les environnements de commutation hautes performances, des chutes occasionnelles sont attendues et normales.

Guides de dépannage

• Dépannage des pertes de sortie sur les commutateurs Catalyst 9000
• Comprendre l'allocation de tampon de file d'attente sur les commutateurs Catalyst 9000
• Assistance technique de Cisco et téléchargements