Matrices de compatibilité, release notes et évolutions du firmware

« Pris en charge » est une affirmation portant sur un triplet : ce module, sur cette plateforme, avec cette version logicielle. Les constructeurs publient ce triplet dans des matrices de compatibilité et des notes de version, et ils le modifient — de nouvelles optiques apparaissent, d’anciennes disparaissent, les vérifications se durcissent. Lire les matrices avant d’acheter et les relire avant de mettre à jour est le travail de compatibilité le moins coûteux qui soit. Cette page montre où se trouve l’information, comment la lire, et comment gérer un parc pour qu’une mise à jour logicielle ne se transforme pas en coupure des optiques.

Où les constructeurs publient leur support

Lisez aussi les notes de version de la version du NOS que vous utilisez : les changements liés aux optiques se cachent sous « resolved issues », « behaviour changes » et « new hardware support ».

Lire une entrée de matrice

Ce qui change avec le logiciel

Une pratique de parc qui évite les surprises

1. Inventaire — consigner le constructeur, la PN, le numéro de série, la révision et le firmware de chaque module par port (depuis le commutateur ou depuis l’établi) dans la CMDB.
2. Figer les versions — traiter la version du NOS comme faisant partie du triplet de compatibilité ; ne pas mettre à jour l’accès et le cœur le même jour.
3. Lire les notes de version pour les éléments liés aux optiques avant chaque mise à jour.
4. Tester sur un commutateur de laboratoire ou canari avec un exemplaire de chaque type d’optique utilisé — les modules tiers et codés en premier.
5. Conserver l’image précédente et un plan de retour arrière ; savoir quels ports sont sujets à l’errdisable.
6. Établir une référence DDM avant et après, pour que les changements de comportement soient visibles en supervision (Surveillance).
7. Suivre l’EOL des PN d’optiques et de leurs remplaçantes, pour que les remplacements correspondent à la matrice.

Optiques tierces et codées dans ce contexte

Un module codé sur une PN OEM est jugé sur la même entrée de matrice que l’original — la plateforme ne peut pas faire la différence si le codage est complet — mais la déclaration de support du constructeur ne s’étend pas à lui, et une vérification plus stricte dans une nouvelle version peut le démasquer. Gardez les modules codés identifiables dans l’inventaire (leur véritable constructeur et numéro de série), testez-les en premier lors des mises à jour, et prévoyez le cas où une version ferme la porte (Optiques tierces, Verrouillage constructeur).

Côté NIC et serveur

Les adaptateurs serveur ont leurs propres matrices (adaptateur ↔ module ↔ pilote/firmware) et leurs propres politiques — certaines familles Intel refusent les SFP non listés à moins qu’un paramètre de pilote ne les autorise ; les adaptateurs Mellanox/Nvidia valident les câbles pour InfiniBand. Les mises à jour de pilote et de firmware changent ces règles tout comme le font les mises à jour du NOS (Recettes de configuration des ports).

Dans CodingBox

Le volet établi de cette pratique de parc : consigner l’identité et la version de firmware de chaque module dans la code database lors du contrôle à réception, comparer les octets d’un module suspect à l’entrée de matrice sur Check transceiver, et conserver la distinction codé/original dans les notes de la base afin qu’un rejet le jour d’une mise à jour puisse être retracé jusqu’au module en quelques secondes.

Les politiques de pilote et de firmware des NIC en détail, par constructeur et par système d’exploitation : Compatibilité des transceivers sur les NIC.

La pratique de parc sous forme de liste de contrôle de mise en service — mise à jour avant configuration, tests canari, référence DDM, test de réception : Sélectionner et mettre en service.