Commutateur Connectrix série B : défauts FOS-849642 et FOS-847091 ;

Produits touchés
Brocade X7-8, X7-4, 7730 et 7720 exécutant FOS v9.1.x ou FOS v9.2.0
Corrigé dans les versions
Brocade FOS v9.1.1c, v9.2.0a et versions

supérieures Seuls les produits de 7e génération sont exposés à un risque.
Les directeurs Gen 7 (X7-8 et X7-4) équipés d’une lame de port FC64-48 et/ou FC32-X7-48 risquent de rencontrer à la fois des erreurs de dépassement de capacité et de vérification. Les lames de port FC32-64 et FC32-48 installées dans les directeurs Gen 7 ne présentent aucun risque de défaillance.
Les commutateurs Gen 7 (G730 et G720) risquent uniquement de subir une défaillance due au débordement de la mémoire tampon. Ces commutateurs ne sont pas exposés et ne risquent pas de rencontrer la condition d’échec d’erreur « Vérification ».
Pour être encore plus à risque, le fabric doit subir une congestion importante, ce qui entraîne une gestion du surabonnement par Traffic
Optimizer. L'exemple suivant RASlog Le message sera observé si ce niveau de réponse a été rencontré :

L’action de gestion du surabonnement par Traffic Optimizer n’existe que dans le firmware FOS v9.1.x. Les produits
Gen 7 s’exécutant sur FOS v9.0.x ne présentent aucun risque de défaillance.

Conditions de risque de défaillance en cas de dépassement de capacité de la mémoire tampon
Pour que la condition de dépassement de capacité de la mémoire tampon se produise, en plus de nécessiter une période de congestion importante, les ports F du directeur ou du commutateur Gen 7
doivent également avoir été configurés de la valeur par défaut à un plus grand nombre de mémoires tampons. Par défaut, FOS attribue
un maximum de 28 mémoires tampons.
Tout directeur ou commutateur Gen 7 dont le nombre maximal de tampons de ports F a augmenté au-dessus des valeurs par défaut utilisées par
FOS est potentiellement à risque, et tout directeur X7-8 ou X7-4 qui exécutait auparavant FOS v9.0.x pourrait être à risque de
rencontrer des erreurs de « vérification ». Dans les deux cas, Traffic Optimizer doit également tenter de gérer le routage des trames en réponse à
un événement de surabonnement causé pendant une période de congestion importante.

Pour déterminer les directeurs et les commutateurs susceptibles d’être à risque, utilisez la commande "portbuffershow" pour afficher l’utilisation
 
de la mémoire tampon Si le total de toute l’utilisation de la mémoire tampon pour les ports sur le même ASIC/puce qui sont également zonés ensemble s’additionne pour atteindre une valeur supérieure à 256 mémoires tampons, le commutateur Gen 7 est considéré comme présentant un risque de dépassement de la mémoire tampon si un événement de congestion grave nécessite une gestion du surabonnement de la part de Traffic Optimizer. La défaillance ne se produira pas lors de chaque événement de gestion du surabonnement, car le nombre de mémoires tampons gérées au moment de l’événement doit dépasser 256 tandis que Traffic Optimizer gère le surabonnement. Toutefois, le fait d’être configuré pour gérer potentiellement plus de 256 mémoires tampons mettra le commutateur en danger.
Dans l’exemple de sortie illustré ci-dessus, si les 8 ports F se trouvent dans la même zone, le commutateur risque de rencontrer un
dépassement de la mémoire tampon pendant que Traffic Optimizer gère une condition de surabonnement, car le nombre total d’utilisation de la mémoire tampon dans cet exemple est de 360.
Toutefois, dans l’exemple suivant où les ports F ne sont pas tous zonés ensemble, ce commutateur ne serait pas en danger, car les deux zones (affichées en vert) totalisent jusqu’à 232 tampons et 128 tampons respectivement.
 
Le nombre maximal de ports utilisés pour la gestion du surabonnement est de 8. Si plus de 8 ports sont zonés ensemble à partir du même ASIC/puce, additionnez les 8 ports présentant les valeurs d’utilisation de la mémoire tampon les plus élevées pour déterminer le risque.

REMARQUE : les directeurs et commutateurs Gen 7 dont le nombre de tampons de ports F par défaut n’a jamais été modifié ne sont pas exposés à ce problème de dépassement de capacité de trame de mémoire tampon. La valeur maximale utilisée par défaut pour les mémoires tampons max./réservées est de 28 pour les produits Gen 7. Toutefois, moins de mémoires tampons peuvent être allouées en fonction du type de commutateur et de la vitesse optique. Les clients
qui n’ont jamais augmenté leur nombre max./réservé de mémoire tampon par défaut ne rencontreront pas le problème de débordement
de la mémoire tampon. Même avec 8 ports zonés ensemble, en utilisant l’allocation par défaut maximale de 28 tampons par port, la valeur totale de l’utilisation maximale de la mémoire tampon n’est que de
224 trames.

« Vérifier » les conditions
de risque de défaillanceOutre le problème de débordement de la mémoire tampon, les directeurs X7-8 et X7-4 peuvent également être exposés au risque de « vérification » des messages d’erreur si les conditions suivantes sont remplies dans cet ordre :

• Directeur X7-8 ou X7-4 précédemment exécuté sur FOS v9.0.x
• Le directeur est ensuite mis à niveau vers FOX v9.1.x
• Le directeur dispose ensuite de ports F qui se déconnectent et se connectent lorsqu’il utilise la version v9.1.x
• Le directeur rencontre alors un événement de surabonnement qui nécessite une gestion de la part de Traffic Optimizer
• Le directeur exécute ensuite un basculement HA (la mise à niveau du firmware provoque un basculement)
• Le directeur rencontre un autre événement de surabonnement qui nécessite une gestion de la part de Traffic Optimizer 

Les directeurs X7-8 ou X7-4 qui remplissent toutes ces conditions, dans l’ordre spécifié, risquent de rencontrer des erreurs de vérification lors de la gestion du surabonnement à partir de Traffic Optimizer.

• Les directeurs X7-8 ou X7-4 qui n’ont jamais été exécutés que sur le firmware FOS v9.1.x ne risquent pas de rencontrer l’erreur « verify » car seul le modèle de programmation v9.1 est utilisé pour tous les ports. Les directeurs Gen 7 doivent avoir été précédemment exécutés avec FOS v9.0.x afin d’être sensibles à ce problème.
• Les directeurs X7-8 ou X7-4 qui ont été démarrés à froid/redémarrés lors de l’exécution du firmware FOS v9.1.x ne risquent pas non plus de rencontrer l’erreur « verify » car tous les ports utiliseront la programmation v9.1 après le redémarrage

Symptômes
Les directeurs et commutateurs Gen 7 qui ont rencontré un événement de gestion du surabonnement observeront l’optimisateur de trafic suivant
RASlog:

D’autres symptômes peuvent apparaître en raison de ces problèmes identifiés :

• Un grand nombre d’erreurs CRC sur une liaison peut être observé, qui ne sont pas corrigées avec le remplacement des dispositifs optiques/câbles
• Les cadres peuvent être ignorés, le crédit sur un lien peut être perdu
• Les ports peuvent être défaillants, l’ASIC peut s’arrêter et être défaillant
• Un directeur peut observer un basculement HA inattendu ou même un redémarrage à froid du directeur
• Les commutateurs peuvent observer un redémarrage à froid

La gestion du surabonnement par la fonctionnalité Traffic Optimizer dans des conditions spécifiques peut entraîner des
scénarios de défaillance ayant un impact sur la transmission des trames ou des ports gérés. Dans les scénarios de congestion sévère, ces défaillances peuvent également
avoir un impact sur les performances d’autres processus de Fabric OS (FOS) actifs sur le commutateur, entraînant des délais d’expiration de la surveillance logicielle
entraînant un basculement HA ou un fonctionnement inattendu du commutateur.

Les directeurs et commutateurs Gen 7 (X7-8, X7-4, 7730 et 7720) qui rencontrent un dépassement de capacité de mémoire tampon de trame lors de la tentative
de gestion et de réacheminement des flux sursouscrits en réponse à un événement de congestion grave peuvent provoquer des erreurs inattendues. Si
le nombre de trames dépasse la mémoire tampon utilisée pour gérer le surabonnement, ces trames excédentaires peuvent
être manquées lors du traitement de Traffic Optimizer. Ces trames excédentaires peuvent potentiellement être remplacées par d’autres trames, ce qui entraîne
des erreurs CRC de trame ou même des défaillances de port si les informations d’en-tête sont écrasées. Dans des scénarios de congestion sévère, la gestion de ces dépassements/excès de trames peut entraîner le blocage d’autres processus FOS, ce qui peut entraîner
des délais d’attente de surveillance. Les processus critiques qui expirent entraînent un basculement HA ou un redémarrage du commutateur perturbateur.

En plus de la gestion potentielle du dépassement de trame, les directeurs X7-8 et X7-4 qui fonctionnaient auparavant sur FOS v9.0.x, puis mis à niveau vers FOS v9.1.x, pouvaient rencontrer des erreurs de vérification après des basculements HA (y compris ceux causés par les mises à niveau du firmware vers des versions supérieures de v9.1.x). Plusieurs messages d’erreur « verify » sont observés lors de la gestion du surabonnement par Traffic Optimizer en raison d’un conflit détecté dans la programmation des ports créés lorsque certains ports ne sont pas tous réinitialisés dans la version 9.1.x. Le conflit entre la programmation de la gestion de la congestion sur les ports qui n’ont jamais été réinitialisés à la version 9.0.x et la gestion de la congestion rencontrée ultérieurement à la version 9.1.x sur les ports qui ont été réinitialisés peut apparaître après un événement de basculement HA.

Solution de contournement
» Les directeurs et les commutateurs « à risque » peuvent désactiver l’action de gestion du surabonnement de Traffic Optimizer.
Exécutez la commande CLI suivante à partir du compte de maintenance pour désactiver le comportement de l’action de gestion du surabonnement
dans Traffic Optimizer

 

 

 

 

Option 1 : effectuez l’action de redémarrage indiquée ci-dessus, puis mettez en œuvre la solution de contournement pour désactiver l’action de gestion du surabonnement à partir de Traffic Optimizer
Option 2 : effectuez une mise à niveau vers une version de FOS avec la solution, puis effectuez l’action de redémarrage indiquée ci-dessus.

La mise à niveau vers une version de FOS avec la solution fournie empêchera le “buffer overflow” mais une fois la condition défaillante rencontrée,
seul un redémarrage à froid de l’ASIC résoudra la condition de défaillance.
La mise à niveau vers une version de FOS avec la solution fournie permet d’éviter l’erreur
« verify » et d’effectuer une restauration automatique à partir de cette condition sans aucune action supplémentaire.

Après la mise à niveau vers une version de FOS contenant la solution, une vérification de la mémoire interne est effectuée pour déterminer si le directeur ou le commutateur a déjà rencontré la panne et nécessite un redémarrage pour récupérer de la condition d’erreur.
Le RASlog suivant s’affiche si la condition d’échec est détectée après la mise à niveau de FOS vers une version avec la solution :

Si le RASlog ci-dessus est observé après la mise à niveau de FOS, cela signifie que le directeur ou le commutateur a déjà rencontré la défaillance de « débordement de la mémoire tampon
» avant la mise à niveau et devra effectuer un redémarrage à froid pour récupérer complètement de la condition d’échec :