Ce que le Catalyst 2960X vérifie dans le dump d'un SFP : code vendeur, nom et MD5, et pourquoi une copie de dump échoue
Je gère le réseau d'un opérateur, le parc de modules est hétérogène, donc je dois régulièrement préparer des modules pour des switchs spécifiques. Je veux enfin comprendre la mécanique de vérification, plutôt que de tester des dumps au hasard.
Ce avec quoi je travaille :
- Cisco Catalyst 2960X-24PS-L, le plus exigeant du parc
- QTECH QSW-3750-28TX-AC et D-Link DGS-3420, sur lesquels les mêmes modules montent sans problème
- modules SNR-SFP+SR et SFP-10G-BX
Dans le dump d'un module accepté sur le Catalyst, je vois au début l'octet du code vendeur suivi du nom en ASCII :
0E 43 49 53 43 4F ...Ce que j'ai essayé : j'ai extrait le dump d'un module qui monte sur le C2960X-24PS-L, et réécrit dans un autre module uniquement le nom du vendeur issu de ce dump. Sur le QTECH et le D-Link, après cela tout monte, mais le Catalyst refuse ce module, bien que les octets modifiés correspondent exactement à ceux du donneur.
D'où ma question sur le fonctionnement de la vérification. Que calcule exactement Cisco et sur quels octets, où le résultat est-il stocké dans le module, et pourquoi le nom de vendeur recopié depuis un dump fonctionnel ne suffit-il pas ? La logique m'intéresse, le reste je le gérerai moi-même.
Comments 6
La mécanique est simple et connue depuis longtemps. Ce n'est pas un champ isolé qui est vérifié, mais un couple : l'octet du code vendeur plus les octets du nom du vendeur. Un MD5 est calculé sur cette séquence, et le résultat est stocké dans le module lui-même ; le switch calcule la même chose et compare.
Reproductible avec des utilitaires standards, rien de spécial n'est nécessaire :
Vous substituez votre code et votre nom de vendeur et vous obtenez la valeur qui doit se trouver dans le module. Parmi les codes réellement rencontrés dans les dumps : 02 - Finisar, 0E - Methode, 11 apparaît régulièrement mais on n'a jamais identifié à qui il appartient. Si le couple code-nom est cohérent et que le hash lui correspond, le module passe sur le C2960X-24PS-L.
Suite au message précédent : montrez ce qui se trouve réellement dans le récepteur. Quel octet de code vendeur y est resté et quel nom se trouve à côté ? D'après votre description, vous avez transféré le nom mais laissé le code ou le hash lui-même issu du module d'origine, et dans ce cas le couple ne correspond plus, et le Catalyst le rejette tout à fait légitimement. Vérifiez les trois éléments d'un coup, pas seulement le champ visible dans la sortie du switch.
Vérifié, tout correspond à votre explication. Chez le donneur c'est 0E puis CISCO, et dans le récepteur j'ai bien réécrit le nom, mais le code vendeur est resté celui d'origine, et le hash aussi était l'ancien. J'ai fait passer les deux combinaisons par xxd -r -p et md5sum : chez le donneur la valeur correspond à ce qui est stocké dans le module, chez celui que j'ai assemblé à la main, non.
Donc il faut transférer le couple en entier, pas champ par champ. Au moins maintenant je sais où regarder et quoi vérifier avant de mettre le module dans le port.
Conséquence importante qu'on oublie constamment : si le code vendeur et le nom ne sont pas cohérents, le module ne passera pas sur le Catalyst même quand le switch autorise les modules non supportés. C'est justement pour cela que des dumps venus d'ailleurs fonctionnent une fois sur deux - ils ont été modifiés partiellement, et la vérification porte sur le couple.
D'où une conclusion pratique sur le volume : dans un dump de 256 octets, seuls les 128 premiers octets sont significatifs, ensuite vient la zone du fabricant. Inutile de transporter l'image entière, mais la première moitié doit être transférée de façon cohérente, y compris des champs invisibles dans la sortie du switch.
D'ailleurs, un dump ne résout pas tout. Dans le Medick SFP-10G-BX, ce n'est pas de la mémoire qui est présente mais un microcontrôleur C8051F392 : il émule A0 et A2 et peut très bien conserver un mot de passe ou une requête propre au vendeur. Là, vous pouvez comparer le couple octet par octet - il ne sera tout simplement pas accepté de l'extérieur. Comme outils que j'utilise réellement, il y a SNR SFP Writer et SFPTotal Plus, mes collègues ont aussi des bricolages maison à base de CH341.
Petite précision pour ne pas induire en erreur ceux qui arriveront ici plus tard. Ce MD5 n'a rien à voir avec les sommes de contrôle MSA : CC_BASE et CC_EXT de la norme SFF-8472 sont calculées par simple addition d'octets et se recalculent en un instant. La vérification propriétaire du vendeur se superpose à celles-ci selon ses propres règles, et rejette le module précisément au moment où les sommes MSA sont pourtant correctes - d'où l'impression que le dump est correct alors que le module n'est quand même pas accepté.
Cisco n'est d'ailleurs pas du tout le pire cas ici : au moins la mécanique est compréhensible et reproductible. Le plus difficile, ce sont HP et Aruba, où la mémoire se comporte de façon interactive et exige des clés - là, les dumps ne suffisent plus.