Le Catalyst 3850 met le port en err-disable quand un ThinkSystem SR650 utilise des optiques SR Lenovo 46C3447

Ce journal tranche la question. gbic-invalid c'est le switch refusant ce qu'il lit comme un module non autorisé, et le contrôle qui se déclenche vit du côté Cisco, pas sur le SR650 et pas dans ESXi. Il s'oppose à l'optique SR codée Lenovo sur ce lien et tue le port avant même que le lien ne soit évalué, ce qui explique aussi pourquoi déplacer des ports et échanger des cordons n'a rien changé pour vous.

Deux lignes en configuration globale :

service unsupported-transceiver
no errdisable detect cause gbic-invalid

La première dit au switch de continuer avec un module qu'il ne reconnaît pas, la seconde empêche err-disable de tuer le port quand ce contrôle CRC échoue. Aucune des deux n'est rétroactive, donc faites basculer le port ensuite et réinsérez la fibre pendant qu'il est down :

interface Te1/0/7
 shutdown
 no shutdown

Enregistrez la configuration une fois qu'il est monté. Si ça ne vit que dans la config en cours d'exécution, le port revient err-disabled après le prochain reload et vous devrez déboguer ça à nouveau à un moment bien pire.

Deux mises en garde. Vous êtes maintenant en dehors de la configuration supportée par Cisco : ils considèrent les optiques tierces comme non testées et le TAC peut refuser un dossier d'interopérabilité qui en implique une, ce qui compte si ce lien est sous contrat. Et service unsupported-transceiver n'est pas un correctif universel. Le même mauvais message de crc lui survit quand c'est le port lui-même qui est l'obstacle, par exemple un slot SFP 1G uniquement avec un module 10G poussé dedans, donc si le port reste down après le basculement, vérifiez d'abord à quelle vitesse chaque extrémité tourne réellement avant d'accuser à nouveau l'optique.